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-.NET testközelben! 


A NetAcademia júniustól elindította intenzív .NET 
felkészítő tanfolyamait, ahol elsőkézből megtanul- 
hatja a legújabb technológiákat. 
2124 - Introduction to Ct Programming for the 
Microsoft .NET Platform 
5 napos intenzív kurzus, ahol részletekbe 
menően megismerjük a Ctt lelkivilágát. 
2063 - Introduction to ASP.NET 
3 napos , átképzés" ASP fejlesztőknek, 
ADO.NET-tel fűszerezve. 
1913 - Exchanging and Transforming Data 
Using XML and XSLT 


Ji s Í d j B 1] s; J ] ] ] ij 5 napban az XSLT-ről, alfától-omegáig. 
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ÖSZÖN 


Talán meglepte kedves olvasóinkat a címlap, mely a barcelonai 
Tech.Ed konferencia jegyében fogant, ám ezzel egyidejűleg e- 
gyetlenegy cikk sem szól magáról az eseményről. Ennek oka 
egyszerű: a konferencia nemhogy nem zárult még le a lapzárta 
pillanatában, hanem jóformán el sem kezdődött. Összesen két be- 
vezető előadáson és egy kiadós ebéden vagyunk túl, de ennyi 
is elegendőnek bizonyult a konferencia fő témájának megálla- 
pításához: .NET! Az augusztusi számban - reményeink szerint — 
közre tudjuk adni az első néhány Barcelonában fogant cikket. 
A konferencia helyszíne a barcelonai olimpia és a világ- 
kiállítás céljára emelt Montjuic 2 épületegyüttes, melyben 
szinte elvész a 9000 résztvevő. 
Néhány statisztikai adat: 9000 résztvevő, mintegy harminc or- 
szágból. 35 Celsius fok, 20 perces várakozás reggelenként a kon- 
ferenciabuszra. Magyarországról több, mint 160-an vesznek 
részt a rendezvényen. Kiosztva 18.000 darab Visual Studio .NET 
Beta 2. A .NET szolgáltatásokat huszonhat programozási nyel- 
ven lehet majd elérni. A számoknál azonban többet mond egy 
kis élménybeszámoló. E havi köszöntőnket rendhagyó módon 
két szerző jegyzi: Fülöp Miklós (F.M.) és Fóti Marcell (F.M.). 
F.M.: A konferencia egészére rányomja bélyegét, hogy a Micro- 
softnak ismét van mondanivalója. A tavalyi rendezvénnyel ösz- 
szehasonlítva ez a megállapítás különösen éles, hisz a rendezők 
akkor is kitettek magukért, de nem sok újdonsággal tudtak szol- 
gálni. Miért? Mert tavaly egy céljait elért, megállapodott Micro- 
soft állt szemben a hallgatósággal. Bill 1975-ös terve régesrég 
megvalósult, hisz minden íróasztalon évek óta ott a PC, Ameri- 
kában már otthonra is a sokadikat veszik a polgárok. Véget ért 
a böngésző, a Linux, a Novell, az SOL és a levelezőkiszolgáló 
háború. Bill valószínűleg nehéz döntés előtt állt: ha minden 
asztalon ott a PC, akkor akár nyugdíjba is mehet :-) 
F.M.: Most azonban megint van követendő cél: a dotnet, mely 
valami hasonló változás, mint a DOS-zWindows váltás. Akkori- 
ban az egyalkalmazásos modellről tértünk át a több program 
párhuzamos, együttműködő futtatására. Ki emlékszik már arra, 
hogy anno nem volt vágólap? Papírral és ceruzával vittük át az 
adatokat egyik alkalmazásból a másikba. Ma is kell papír és ce- 
ruza: másképp nemigen tudjuk saját adatainkat átvinni egyik 
webkiszolgálóról a másikra. Ezen (is) változtat a .NET. 
F.M.: A .NET több, mint amit elképzelünk. 
0 Új fejlesztési paradigma (menedzselt kód, garbage collec- 
tion stb. lásd múlt havi számunk e tárgyban született cikkét) 
Új operációs rendszer, hihetetlenül sokat tudó új API-kkal 
(ha hívhatjuk egyáltalán API-nak a .NET névtér objektumait) 
Mm Új, szabványos alapokra helyezett kapcsolattartás. Arccal 
az XML felé! Vesszen az RPC, itt az XML alapú SOAP! 
Még meg sem tanultuk az LDAP-ot, LDIF-et, de már lassan 
nem is érdemes. Még az Active Directory is XML alapú lesz. 
A nem is távoli jövőben éppolyan könnyedén lehet majd 
XML kimenetű SOL lekérdezéseket futtatni az Active Directo- 
ry-n, mint amilyen egyszerűen megtehető ez ma az SOL 
2000-rel. Az XML nélkülözhetetlen abban a stratégiában, 
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melynek célja az alkalmazások eljuttatása az összes eszközre. 
F.M.: Tehát a .NET project keretében egyszerre, egyidőben 
kerül sor a Windows operációs rendszer objektumalapokra 
helyezésére, és a Windows, mint egyeduralkodó ügyfélol- 
dali rendszer kiváltására mobiltelefonokkal, hordozható ke- 
tyerékkel, hűtőszekrényekkel. Nem mellesleg az új progra- 
mozási nyelv is születik: a Ctt (a nyelvről részletes írás jelent 
meg lapunk tavaly szeptemberi számában, mely a weben tel- 
jes egészében elolvasható a [1] címen). 

F.M.: Az informatikusok nyitottak a hülyeségre is. Mi sem bizo- 
nyítja ezt jobban, mint a Visual Basic.NET hatékonyságát igazo- 
ló bemutató. Példaképpen láthattuk a Bill Gates által 1981-ben 
(vagy mikor?) írott donkey.bas , játékprogramot", mely karakteres 
grafikával" kápráztatta el az akkori fejlesztőket: autónkkal csa- 
csikat kellett kerülgetni. Abban az időben a programsorok sor- 
számozásának megszüntetése volt a VisBas melletti fő fegyver- 
tény. Majd bemutatták ugyanennek a játéknak VB.NET-tel ké- 
szített változatát: real-time 3D grafika és hang, valósághű, cse- 
rélhető identitású webcsacsik, force-feedbackes kormányzás! 
F.M.: Minden Tech.Ed elmaradhatatlan feltétele a számítógép- 
hez, Internethez szokott hallgatóság ellátása az életfontosságú 
sávszélességgel. Ennek hagyományos módja az úgynevezett 
Communications Network, mely - immár hagyományosan - képtelen 


ja a kulcsot. Azonban ebben az évben ez nem sokakat zavar, mert 
drótnélküli hálózaton a teljes épületben magunkkal cipelhetjük 
az éltet adó sávszélességet. A Compag vagy nyolcezer iPag kézi- 
számítógéppel kedveskedett a jelenlévőknek, melyet ingyen és 
bérmentve használhatunk a konferencia teljes időtartama alatt. 
F.M.: Ha már wireless, beszéljünk egy keveset a mobileszkö- 
zök használatáról. Vajon mekkora erőfeszítésbe telik egy fej- 
lesztőnek elkészíteni egy alkalmazás különböző eszközökre 
optimalizált változatát? A Visual Studio .NET használatával bi- 
zony nem sokba. Az ASP.NET például automatikusan böngé- 
szőre (telefonkijelzőre) optimalizálja a webes objektumokat. . . 
F.M.: A Microsoft azt is célul tűzte ki, hogy a hagyományosan 
Microsoft-vonalon dolgozó 8 millió fejlesztőn kívül a .NET-et 
elérhetővé tegye gyakorlatilag az összes élő programozó számá- 
ra: VB, VBScript, C, C-t, Ctt, Java, Perl, Python, Rexx, Cobol (/), 
Fortran (!), Eiffel és még ki tudja milyen ismeretlen programo- 
zási nyelven lehet majd - állítólag - egyenértékűen dolgozni! 

A mai nap programjából már csak az esti Country Drinks van 
hátra, elbúcsúzunk. Ígérjük, hamarosan fényképekkel illusztrált 
élménybeszámolót tárunk kedves olvasóink elé a [2] címen. 


Fóti Marcell és Fülöp Miklós 


A cikkben szereplő URL-e 
[11] http://technet.netacademia.net 
[2] http://technet.netacademia.net/teched2001 
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rözíppeutáan a felhasznátó 





e. Itt az Office XP! 
gáz Megjelent az Office XP, a Microsoft irodai ki- 
j Bá szolgálócsomagjának legújabb verziója. Az 
Edlőfficee [1] címen részletesen olvashatunk a termék 
újdonságairól és előnyeiről. 





Megjelent az MSIA 

Az új szoftverlicencelésre történő lassú átállás, valamint a 
kisvállalatok szoftvergazdálkodásának megkönnyítése je- 
gyében 2001 júliusában megjelent a Microsoft Inventory 
Analyzer nevű programocska, mely önálló alkalmazásként 
futva (nem igényel sem SMS-t, sem SOL Servert) lehetővé te- 
szi, hogy akár a hálózat összes gépén felmérjük a telepített 
(egyelőre csak MS) szoftvereket. A 3,36 MB-os programocs- 
ka az [2] címről tölthető le. Ez a régen várt eszköz renge- 
teg rendszergazdának oldja meg mindennapi gondjait: va- 
jon hány Word, Excel és ilyen/olyan operációs rendszer van 
telepítve a hálózatban? 





BZ. a 


Welcome ta the MSIA Wizard 





EST] . cen 


2 DET) em] 
a Az MSIA varázslóval akár kiszolgálótermékeket is ke- 
reshetünk a hálózatban 





HÍREK..HÍREK..HÍREK 





Talán már megszokhattuk, hogy jelentős számú Microsoft 
szoftver kis, külső cégnél kezdte pályafutását (NLBS, Front- 
page, Excel stb.) , az MSIA mégis egyedülálló a maga nemé- 
ben: Indiából származik [3]! Fontos megemlíteni, hogy a 
Microsoft folyamatosan frissíti, és az [2] címen elérhetővé 
teszi a felismerési adatbázist, mely már jelenleg is igen je- 
lentős készlettel rendelkezik. A futás eredményéről Excel, 
HTML, de akár TXT formátumban kaphatunk jelentést. 


Lapzárta után: Exchange 2000 Server Service Pack 1 
Lapzárta után érkezett a hír, hogy megjelent végre a 
régóta várt első javítócsomag az Exchange 2000 Ser- 
ver-hez. Az SP1 a [4] címről tölthető le, és a hibajaví- 
tások mellett számos újdonságot is tartalmaz. Az An- 
tiVirus API-k támogatása mellett (amiről a 13. oldaltól 
részletesebben is szólunk) több ponton továbbfejlesz- 
tették a webes felületet (OWA) - például a magyar 
nyelv támogatását; új az Exchange Server 5.5 Migrati- 
on Tool, vagy éppen az ugyacsak Exchange 5.5-ből is- 
merős Mailbox Manager. Kötelező javítás! 


[dada ESZA JALTAI 


[11 http://www.microsoft.com/hun/product/OfficeXP.asp 
[2] http://www.microsoft.com/piracy/msia 
[3] http://www.aditi.com/ 


[4] http://www.microsoft.com/exchange/downloads/2000/sp1.asp 


http://vilagokorseg.hu 
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WINDOwS 2000 


Network Monitor 


Az elmúlt alkalommal megígértem, hogy most a hitelesítések 
hálózati forgalmát vesszük sorra. Ígéret szép szó, nem tar- 
tom - úgy jó. Nem tartom a szavam, mert közben lezajlott 
egy NetAcademia tanfolyam a Windows 2000 fürttechnoló- 
giákról, s ezen készítettem néhány izgalmas pillanatfelvételt 
az NLBS (Network Load Balancing Service) működéséről, me- 
lyek értéke vetekszik egynéhány ritka műkincs, például a Mo- 
na Lisa, vagy egy ritka bélyeg értékével. Ezt osztom meg 
önökkel ebben a cikkben, gazdagodjunk mindannyian! 


Fürt és fürt 

A Windows 2000 sokféle beépített fürtözési lehetőséggel ren- 
delkezik. Van megoldás nagy rendelkezésre állású rendszer 
kiépítésére (Shared SCSI, vagy Failover Cluster) éppúgy, mint 
terheléselosztás használatára akár 32 gép között (NLBS). Ezek- 
ről ejtsünk pár szót, ha már volt szerencsém heteket tölteni a 
technológiákkal, s mind a könyökömön, mind a fülemen ez jön. 


Failover Cluster 

Osztott SCSI tárolón alapuló, vagy képletesebben , váltott lo- 
vakkal" fürt. Ez a fürtmegoldás - tipikus kiépítésben - két szá- 
mítógép (Node) egyidejű működtetésével biztosítja, hogy a 
rajta futó szolgáltatások mindig elérhetőek legyenek, akár 
még az egyik gép teljes kiesése esetén is. Ebben a modellben 
központi szerep jut a két (vagy Datacenter Server esetén több) 
Node között elhelyezkedő osztott tároló alrendszernek, amely- 
nek lemezeit a fürt végpontjai közösen használják. Ezek felett, 
úgynevezett virtuális kiszolgálókként, mindegy a kibertérben 
futnak az alkalmazások. Vagy méginkább: a Node a ló, a vir- 
tuális kiszolgáló a lovas, mely egy adott pillanatban egyszerre 
egy gép hátán ül, azt hajtja, sarkantyúzza. Ha a gazdagép ren- 
detlenkedik, vagy leáll (a ló megdöglik), a hűtlen virtuális ki- 
szolgáló szedi a sátorfáját, és IP címestül, mindenestül átül a 
másik, hibátlan Node-ra (Failover). Akárhol ül is a lovas, az 
adatokat mindig eléri, hisz azokat nem a lovon tárolja, hanem 
az istállóban: az osztott elérésű RAID alrendszeren. 





Exchange 
Virtual Server 


NodeA NodeB 


0 Server Cluster Failover: NodeA kiesése esetén a rajta 
futó virtuális kiszolgálók átköltöznek a hibátlan NodeB-re 
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A Failover Cluster egyetlen különleges hálózati forgalma a 
két Node között zajló úgynevezett szívverés (Heartbeat), 
melynek értelmezéséhez sajnos a NetMon nem sokat tesz 
hozzá: nincs ilyen parser benne. 


NLBS terheléselosztó fürt 

Az NLBS gyökeresen más elveken működik, mint az előbb em- 
(ített Failover Cluster. Míg az előző fürtnél igen szigorú szoft- 
ver- és hardverkövetelményeknek kellett teljesülniük (osztott 
SCSI alrendszer, maximum 2 Node Advanced Server esetén, úgy- 
nevezett Cluster Aware (fürtképes) alkalmazások stb.) addig az 
NLBS-hez semmi nem kell. A Node-ok száma is jelentősen 
több lehet: maximum 32. Valójában az NLBS, bár rendszer- 
komponens, idegen testként ékelődik be a Windows hálózati 
architektúrájába, és mindenkit ott csap be, ahol tud (mimik- 
ri). Még az NLBS-t futtató gazda operációs rendszer is csak 
les", hogy mi történik, a rajta futó szolgáltatások ugyanis 
csak akkor kapnak adatot a hálózatról, ha ezt az NLBS eszköz- 
meghajtó jónak látja. Mivel maga az oprendszer is csak ,les", 
nem meglepő, hogy az NLBS-en fürtben futtatott alkalmazá- 
soknak sincs halvány lila elképzelésük arról, hogy fürtben 
vannak. Egy IIS-nek, vagy egy Terminal Services-nek sejtelme 
sincs arról, hogy ők valójában - mondjuk - 32-en vannak! 

A mimikri üzemmód az NLBS történelmi múltjából eredő 
feature, ugyanis nem Microsoft rendszerkomponensként 
kezdte az életét, hanem Convoy Cluster Software néven 
egy pici bété forgalmazta még az NT4-hez. Ez a zseniális 
kis cég azután felvásárlás áldozatául esett, így született 
előbb a WLBS (A Convoy NT4-es elnevezése) majd az NLBS 
(a Convoy Windows 2000-es neve). 

Az egész fesztivált a 63 kilobájtos (!) WLBS.SYS csinálja, 
mely minden tagkiszolgálón közvetlenül a hálózati kártya 
meghajtója felett, de a TCP és UDP réteg alatt beékelődik 
a rétegzett hálózati architektúrába, és elvégzi a szükséges 
műveleteket ahhoz, hogy a fürt tagjai egységesen visel- 
kedjenek a munkaállomások felé. 


Az NLBS működése 

Az NLBS tisztán TCP/IP trükkökkel dolgozik. A fürtbe kötött 
számítógépek az NLBS üzembe helyezésekor közös (!) IP cí- 
met kapnak (A régi egyedi címüket is megtarthatják persze. 
Már az is a WLBS.SYS okosságának tudható be, hogy nem kez- 
denek sírni a gépek IP cím ütközés miatt). Tehát lesz mond- 
juk 32 gépünk, közös IP címmel. Ebből kitalálható, hogy a 
munkaállomások kérései a fürt összes tagjához befutnak. A 
WLBS.SYS-ek pedig szépen eldöntik, hogy a sok Node közül 
melyik vegye magára a kérdést, melyik válaszoljon. 
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a Az NLBS fürtben - a közös IP cím miatt - mindegyik tag 


megkapja a felhasználó kérését, de csak egyikük válaszol 


Ez roppant egyszerűen hangzik, de a valóságban nem az. 

Ugyanis nincs idő arra, hogy a WLBS.SYS-ek a kérés beér- 

kezésekor nekiálljanak egyeztetni a többi ikertestvérrel, 

hogy melyikük érne rá jobban a feladat kiszolgálására. Ha 
az egyeztetés az igény beérkezésekor történne, odalenne 

a teljesítménynövekedés. A megvalósított szellemes meg- 

oldás ennél sokkal nagyobb teljesítményt biztosít: 

1. A fürt tagjainak beállításakor, vagy a fürtszabályok módosí- 
tásakor a tagok gyorsan előre leosztják egymás között a 
lapokat, azaz jó előre megállapodnak, hogy a világ mind- 
en sarkából érkező kérésekre melyikük fog reagálni (a la- 
pok leosztását a fürt konvergálásának nevezik hivatalosan, 
s erről a tényről bejegyzés készül az Event Logba). 

2. A kérés beérkezésekor - amely a közös IP cím miatt mind- 
egyik taghoz eljut - mindegyik gép önállóan eldönti, 
hogy a leosztott lapok alapján vajon övé-e a feladat. 
Ha igen - a WLBS.SYS továbbengedi a kérést az op- 
rendszernek, s ez a gép válaszol. Ha nem - a 
WLBS.SYS eldobja a csomagot. 

Azt gondolhatnánk, hogy ezzel vége is minden load balance 
lehetőségnek, dinamikus terheléseloszlásnak, hisz ha az elő- 
re leosztott zsugák között nincs ott egy lap, akkor nincs ott. 
Ám valójában a konvergencia során nem IP tartományokat 
osztanak el egymás között, hanem mindegyik tag közös 
szabályokhoz jut a saját DINAMIKUS döntésének megho- 
zatalához! Vagyis a Node-ok összebeszélnek, és azután 
ahhoz tartják magukat. Megbeszélik a terheléselosztás 
szabályait (portok, címek, arányok, affinity stb.), majd ez- 
zel felszerelkezve egyedileg, egymástól függetlenül dönte- 
nek egy-egy kérés megválaszolásáról - és sosem akadnak 
egymással össze! Zseniális! 
A beállítható terhelési szabályokat most nem elemezném, 
hisz a Network Monitor miatt gyűltünk itt össze, így las- 
san rátérünk a lényegre. Ehhez meg kell ismerkednünk az- 
zal, hogy vajon hogyan képesek a gépek közös IP címre 
reagálni. Úgyvan. Közös MAC addressel! Két módon érhető 
el közös MAC Address használata az NLBS alatt: 

"0 Unicast módban a kártyák elveszítik gyári eredeti MAC 
Addressüket (Hoppá!!), mert az NLBS mindegyik Node 
gépen azonos MAC Addresst vés a kártyákra. (A vésés 
túl erős kifejezés: reboot után visszajön a gyári MAC). 
Az eredeti MAC Address elveszítésével ezek a gépek 
többé a "-?$"D életben nem lesznek külön-külön 
megcímezhetők, így jó előre tessenek felmásolni rájuk 
a közös weblapokat, mert később már ezen a kártyán 
keresztül nem lehet! Sőt, távolról egyáltalán nem fog- 
juk tudni megkülönböztetni a gépeket, egyszerre csak 
egyikük fog válaszolni - hisz erre való a fürt. Ez az 
üzemmód eléggé értelmetlen. 

"I Multicast módban a kártyák megtartják eredeti MAC Add- 
ressüket, és ezzel a gépek is megtartják egyedi elérhető- 
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ségüket, menedzselhetőségüket, s a meglévő, gyári ere- 
deti MAC Address mellé kerül fel egy Multicast MAC, 
melyre a fürt tagjai ,harapni" fognak. Ez az üzemmód a 
tökéletes választás, ezen a nyomon haladunk tovább. 

A Multicast MAC Address képzésének szabványos formája a 

következő: vedd a kártyához rendelt Multicast IP címet, 

és annak utolsó három bájtját tedd be a MAC Address 
utolsó három bájtjába, az első három bájt pedig legyen 


01-00-5E. Valahogy így: 
EZNKENKENEN 
Mac Aaress [or Too TETTEST zo Ter 


a A Multicast MAC Address boszorkánykonyhája 


IP cím 


(A Multicastról a BYTE magazin júniusi számában megjelent 
cikkem értekezik ennél részletesebben, ezt az ábrát is on- 
nan loptam vissza.) 

Ezek után már csak azt kell biztosítani, hogy a munkaállo- 
mások ARP kéréseire ez a Multicast MAC jöjjön vissza. 


Szabványok határán 

De megint bökkenőbe ütközünk, ugyanis itt nem valódi 
Multicastról van szó, ahol egy adó kiszolgál egy halmaz ve- 
vőt, hanem ál-Multicast, ami valójában Unicast - legaláb- 
bis a fürtöt használó munkaállomások szemszögéből. Ez a 
gond igazán nagy gond, ugyanis az eredeti Multicast szab- 
ványban [2] szó sincs ARP-ról; a Multicast csoporthoz csat- 
lakozni az IGMP protokoll segítségével lehet. Ráadásul Mul- 
ticast IP címekkel (D osztály, 224.0.0.0-239.255.255.255) 
sok végpont -beleértve a Windows operációs rendszereket 
nem lenne hajlandó Unicast forgalmat kezdeményezni. 
Emiatt az NLBS trükkhöz folyamodik: ha már ál-Multicast, 
legyen teljesen spéci! Ezért a fürt közös címe NE Multi- 
cast, hanem rendes, kutyaközönséges IP cím legyen, in- 
nentől a munkaállomások valóban ARP-vel fognak hozzá 
MAC Addresst keresni. A Multicast MAC Address sem a 
szabványban leírt 01-00-5E kezdetű lesz, hanem 03-BF, 
amely még mindig csoportos cím ugyan, de lokális (MAC 
Addressből is van lokális tartomány, úgy kell használni, 
mint IP-nél a belső címeket! Bizony!) 

Nézzük meg e varázscímeket a Network Monitorral! E hó- 
napban az [1] címről az NLBS.CAP fájl tölthető le, amely- 
ben egy munkaállomás megpingel egy NLBS fürtöt. Pár ol- 
dal múlva ebből ki tudjuk majd olvasni, hogy a fürtnek 
hány csomópontja volt. A fájlnak vizsgáljuk most meg a 
harmadik csomagját (ICMP Echo), keressük meg a címzett 
MAC Addressét. Eddig még egyszer sem boncolgattuk ma- 
gát a MAC Addresst, úgy tekintettük, mint monolitikus, 
felbonthatatlan számot. Most azonban kattintsunk rá ket- 
tőt, bontsuk ki! Ezt kell látni: 





ETHERNET: Destination address : 03BFCOA8040A 
ETHERNET: .......1 - Group address 
ETHERNET: ......1. - Locally administered address 





A legelső bájt alsó bitje mutatja, hogy ez egy csoportos 
MAC Address (Group Address), a második bit pedig arról 
árulkodik, hogy ez egy belső, lokális MAC Address. 

Ha pedig decimálissá alakítjuk a számsorozatot (3-191- 
192-168-4-10) a NetAcademia tanfolyamok hallgatói fel 
fogják ismerni az egyik tanteremben használatos IP címet 
a MAC Address utolsó négy bájtján (192.168.4.10). 
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A következő ábrán egy pillantás erejéig megtekintjük az 
NLBS fő párbeszédpaneljét annak érdekében, hogy átfogó 





Custer Parameters ] Host Parameters . Port Rules ] 








Port range E A te [554 

Protocols CICP CUDP G Both 

Filtering mode Alinly C None G Singe C ClassC ! 
€ Multiple hosts) Load weight FA ar Eaual ] 
C Single host "Handiing priorily 

CöDiatd [AGA [0 6ogy ]/. Bereve ] 
Start End Protocol Mode — Priority Load Affinty 


o 65535 Both 


Multiple 


Egual Single 





Cancel [7 
a Az NLBS portszabályai 


Jól látható, hogy a WLBS.SYS terheléselosztási és egyéb szabá- 
lyai, szűrései mind TCP, mind UDP portokra beállíthatók - 
másra azonban nem! A fenti ábra tanúsága szerint ha a fürt 
csomópontjára beérkező kérés nem TCP és nem is UDP, akkor 
ez nem esik az NLBS fennhatósága alá! Jól jegyezzük meg: az 
NLBS csak és kizárólag a TCP és UDP protokollok forgalmát für- 
tösíti. Vajon mit tesz a WLBS.SYS a szabályok alól , kilógó" 
csomagokkal (például ARP-vel, ICMP-vel, IGMP-vel, GRE-vel 
stb.)? Nem dobhatja el, hisz ezek nélkül nincs élet. Tehát 
átengedi, felküldi az operációs rendszernek, amely válaszol rá. 
Lássuk az NLBS.CAP fájlban az ARP protokollt! Szűrjük meg 
az NLBS.CAP fájlt, hogy csak ARP protokoll maradjon a sze- 
münk előtt. Hány csomagra számítunk, ha elárulom, hogy 
a felvétel zajmentes, tiszta környezetben készült? Én ket- 
tőre számítanék: egy ARP kérésre és egy válaszra. Ám ne- 
künk három ARP csomagunk van... 


ARP az NLBS fürtben 

A vak is láthatja: egy ARP kérdésre két válasz érkezett! 
Ahogy a fenti okfejtésből talán következtethettünk rá: a fürt 
összes csomópontja (mind a kettő :) válaszolt az ARP kérés- 
re, mégpedig az alábbi ábra szerint nem a fent levezetett 
közös MAC Addressel, hanem a hálókártyák saját, beépített 
fizikai címével (00024A5095EB8 és 0002A509618B)! 







1. 1 
1.74250S OOOZASO96LEB 0090272CELZ9 ARP RARP ARP: 





ply. g Pp 
Reply, Target IP 


o Egy ARP kérdésre két válasz? És két különböző címről? 


Ajaj! Mi lesz itt? 

Vajon mi kerül szerencsétlen munkaállomás ARP cachébe? 
Az a MAC Address, amelyik előbb válaszolt (mert az győz)? 
Vagy amelyik később (mert felülüti a korábbi választ)? De 
az tisztán látszik, hogy a beígért Multicast MAC Address- 
nek nyoma sincs. Hacsak... 

Hacsak ki nem bontjuk ezt az átkozott ARP Reply-t! 
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ETHERNET: ETYPE -— 0x0806 : Protocol -— 
Address Resolution Protocol 
ETHERNET: Destination address : 
ETHERNET: Source address : 0002A5095EB8 
ETHERNET: Frame Length : 60 (0x003C) 
ETHERNET: Ethernet Type : 0x0806 (ARP: 
4 Resolution Protocol) 

ETHERNET: Ethernet Data: Number of data bytes 
4 remaining - 46 (0x002E) 

ARP RARP: ARP: Reply, Target IP: 192.168.4.200 

3, Target Hdwr Addr: 0090272CE129 
ARP RARP: Hardware Type - Ethernet (10Mb) 

ARP RARP: Protocol Type - 2048 (0x800) 
ARP RARP: Hardware ess Length -— 6 
ARP RARP: Protocol ess Length — 4 
ARP RARP: 
ARP RARP: 
S 03BFCOAB040A 
ARP RARP: Sender!s Protocol Address - 
4 192.168.4.10 

ARP RARP: Target"s Hardware Address -— 
4 0090272CE129 

ARP RARP: Target!"s Protocol Address - 
S 192.168.4.200 

ARP RARP: Frame Padding 


ARP: 


0090272CE129 


zo 


Address 





(0x6) 
(0x4) 


Ha összevetjük az O helyen olvasható MAC Addresst, (amely 
a feladó címe) a Ö ponton látható címmel (mely az ARP vá- 
lasz tartalma szerinti feladócím) azt tapasztaljuk, hogy ez az 
ARP csomag kissé , hibás": látszólag nem attól a géptől jön, 
mint aki magáénak érezte a kérdéses IP címet! (És ez a cso- 
da azután mégegyszer befut szerencsétlen munkaállomáshoz 
a fürt másik csomópontjáról is: győzze feldolgozni!) Amíg 
ugyanis Ethernet szinten a hálókártya eredeti MAC Addresse 
szerepel, addig a beágyazott ARP-ben már az a Multicast 
katyvasz van, amit egy oldallal korábban elemeztünk! A fürt 
tagjai Ethernetszinten letagadják a Mulitcast jelenlétét, míg 
a beágyazott ARP-ban már ott virít a Multicast MAC! 

Miért, oh miért? 

S ha a kezdeti kapcsolatfelvételkor használt ARP ilyen ,leta- 
gadós", akkor vajon a többi hálózati forgalom milyen lehet? 


Fürtök és switchek 

A válasz nem a Microsoft háza táján keresendő. Bizonyos há- 
lózati elemek MAC-kezelési furfangjai miatt van szükség a 
Multicast MAC elrejtésére a válaszcsomagokban. Hogyan is 
működik egy switch? Virtuális pont-pont kapcsolatot alakít ki 
a kommunikáló felek között arra az időre, amíg a csomag át- 
kerül a címzettől a feladóhoz. A switch a kommunikáló felek 
közt ,félúton" állva nulla milliszekundum alatt képes eldön- 
teni, hogy melyik két portját kell összekötnie egy adott cso- 
mag elszállításához. Erre a rendkívül gyors cselekvésre azért 
képes, mert minden portjához megtanulja az azon lógó gép 
MAC Addressét - egyszerűen kiolvassa és megjegyzi a rajta 
áthaladó forgalomból. Sajnos a switcheket nem készítették 
fel NLBS-re, nem igazán van olyan szabály bennük, hogy 
egyszerre X portot kössenek össze. Még meg is bolondulhat 
némelyikük, ha több portján egyidőben ugyanaz a MAC Add- 
ress bukkan fel. Az a biztos, ha nem hagyjuk, hogy , megta- 
nulja" a Multicast MAC-et, hanem eldugjuk előle. Bújócska. 
Ennek záloga, hogy válaszcsomag Ethernet fejlécében sohase 
jelenjen meg a Multicast MAC, hogy switch pajtás ne tudja 
onnan kiolvasni és memorizálni. Emiatt válaszolnak a közös 
MAC Addressű fürtvégpontok a saját MAC-kel! 
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vesesese 5; Kérdés (Multicast MAC-ra) 






































a A feladó fürttagok sosem a Multicast címmel válaszolnak 


Ha valaki hubot használ, vagy turbóokos switch áll ren- 
delkezésére, a bújócskát ki is kapcsolhatja a 


HKEY LOCAL MACHINENSYSTEMÍCurrentControlSetN 
5, Services WLBSNParametersMaskSourceMAC 


érték nullázásával. Én nem tenném... 


PING a fürtre! 

A munkaállomás a fenti ARP Reply csomagokból kihalászott 
Multicast MAC címet használatba véve ICMP Echo-ba kezd. 
Lássuk a fürt pingelését! A fenti MaskSourceMAC bekapcsolt 
állapotában zajló ICMP forgalom könnyebb értelmezése ér- 
dekében a MAC Addresseket elnevezésekkel láttam el. 
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FITT 
ICHP 
ICMP 
ICHP 
ICHP 
ICHP 
ICHP 
ICHP 
ICHP 
ICMP 


5 1.742505 Node A MAC 
6 1.75Z520 Noda B MAC 
7 2.743945 munkaallonas 
8 2.742945 Node B MAC 
9 2.743945 Node A MAC 
1 3.745385 munkaallonas 
1 3.745385 Node B MAC 
1 2.745985 Node A MAC 
1 4.746825 munkaallonas 






Echo Reply: To 192.168.0 
Rcho: Fron 192.168.04.20 
Echo Reply: Te 192.169.0 
Echo Reply: To 192.168.0 


Kozos MAC 
munjkoallonas 
munkaallonas 
Kozos MAC 

munkaallonar 
munkaallonas 





Echo Reply: To 192. 
Echo Reply: To 192.168. 
Echo: Fron 192.168.04.2! 
1 4.746925 Node B MAC 
1 4.746825 Node A MAC 


kez Nee 


[Comment For Summary 


ICHP 
Icnp 


Bcho Reply: To 192.166.0 


Echo Reply: To 192.168.0 








FENT GHZ 





a Egy ICMP Echora két válasz? 
Az ábra lényege így foglalható össze: 


Munkaallomas -3 ICMP Echo -3 Kozos MAC 
Munkaallomas €- ICMP Reply €- Node B MAC 
Munkaallomas €- ICMP Reply €- Node A MAC 


A pingelő parancssorban egyébként csak egyetlen válasz 
látszik, kizárólag a NetMon számára tárul fel a valóság. 
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Furcsa példáim láttán esetleg egyesekben az a kép ragad 
meg, hogy az NLBS fürt használhatatlan, mert mindig min- 
den csomópont válaszol a munkaállomások kérdéseire, s ez- 
zel eldugítja a hálózatot. Ne tévedjünk, eddigi példáim 
nem az NLBS üzemszerű működésére vonatkoznak! A TCP és 
UDP fölött futó alkalmazások (például IIS, Terminal Services 
stb.) természetesen nem ezt a multiválaszolós hálózati for- 
galmat mutatják, hisz azokra hatnak a portszabályok, és a 
WLBS.SYS csak egyetlen fürttag válaszolását teszi lehetővé. 


Az NLBS korlátai 

Most, hogy ,mindent" tudunk az NLBS viselt dolgairól 

összefoglalnám a működtetés főbb kereteit: 

"0 Nem használható ez a fürttípus olyan környezetben, ahol 
valamelyik hálózati elem (például útválasztó) nem viseli 
el az ál-Multicastot (rendes IP címhez Multicast MAC). 

"8 Nem lesz elérhető az NLBS fürt akkor sem, ha valamelyik 

hálózati elem nem tolerálja azt a működésmódot, 

hogy nem arról a MAC Addressről érkezik a válasz, 

ahová a kérdés irányult (ilyenkor kipróbálhatjuk a 

MaskSourceMAC kikapcsolását). 

Legkönnyebben read only alkalmazások (IIS, Terminal 

Services, Proxy) futtatására használható, mivel ilyen- 

kor nem kell gondoskodni a fürt csomópontjain szét- 

szórtan felbukkanó adatok összesítéséről. 


AppCenter Server 

A fürt beüzemeléséről egy szót sem ejtettem, s nem vélet- 
lenül. Nem egyszerű ugyanis puszta kézzel kialakítani 32 
azonos paraméterezésű csomóponti gépet. Nem beszélve a 
változások követéséről! Megállapítottuk, hogy az alkalma- 
zások (például IIS) nem tudják, hogy fürtön futnak. 
Emiatt nem is képesek a megváltozott adatokat (például 
ASP lapokat, ActiveX vezérlőket stb.) szinkronizálni. A ha- 
marosan megjelenő AppCenter Server a fürtök körül felme- 
rülő napi feladatok ellátásában nyújt hathatós segítséget. 
Két kattintással elvégezhetővé válik új fürtcsomópontok 
teljeskörű, alkalmazásszinkronizációs telepítése. Ezzel a 
termékkel külön cikkben fogunk foglalkozni. 


Fóti Marcell 
marcellfonetacademia.net 
MCSE, MCT, MCDBA 
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A Microsoft Exchange 2000 Serverben már a neve alapján is el 
tudjuk képzelni, hogy mit csinál az Information Store szolgál- 
tatás, illetve azt, hogy mire jó az egyes protokollokat meghaj- 
tó Internet Information Services komponens, de vajon tudjuk- 
e pontosan, hogy mit is csinál a System Attendant? Ebben a 
cikkben megpróbálom összefoglalni a Sysem Attendant Service 
legfontosabb funkcióit, illetve, hogy kell-e rajta bármit is han- 
golni, és ha kell, akkor azt hol és hogyan tehetjük meg. 





Mit is csinál a System Attendant? 

A System Attendant (SA) több egymástól eltérő funkciót 

megvalósító szálat futtat magában. Ezek a szálak nem külön 

processzként futnak, ezért nem látjuk ezeket a Services app- 

let, vagy a Task Manager futtatásakor a futó szolgáltatások, 

processzek között. Ennek teljesítményszempontból van sze- 

repe, a szálak közti kontextusváltás sokkal kevesebb erőfor- 

rást igényel, mint a processzek közti váltás. Viszont az ese- 

ménynaplóban és a különböző információforrásokban gyak- 

ran úgy találkozunk ezekkel a SA belsejében futó szálakkal, 

mintha külön szolgáltatások lennének. Ezért fontos ponto- 

sabban megismernünk a System Attendantot. 

Nevesített szolgáltatásként futó szolgáltatások: 

"0 Metabase Update Service - IIS metabase és AD közötti 

replikáció 

Recipient Update Service - a levelezésbe bevont címtár- 

objektumok különböző címlistákhoz rendelését végzi 

0 DSAccess Service - az Exchange 2000 AD elérését biztosítja 

b DSProxy Service - régebbi MAPI kliensek címlistaeléré- 
sét biztosítja 

Nem nevesített szolgáltatásként végrehajtott SA funkciók: 

"8 Levelezésbe bevont nyilvános mappákhoz tartozó cím- 

tárobjektumok létrehozása és törlése 

Emeltszintű biztonság bekapcsolásakor a bizonyítványok 

továbbítása a felhasználók részére 

Levelesláda-kvóták figyelése, figyelmeztető üzenetek és 

tiltások generálása 

Törölt elemek kétfázisú eltávolítása 

Message Tracking log kezelése 


Ve. 


$ 


Metabase Update Service (MUS) 

Az Exchange 2000 szorosan integrálódik a Windows 2000 
alapszolgáltatásai között nyilvántartott Internet Information 
Services 5.0 (IIS) komponensbe. Az Exchange 2000 telepíté- 
sekor frissíti az IIS meglevő protokollmeghajtóit (SMTP, 
NNTP), és újakat is telepít (POP3, IMAP4). Az IIS egy külön 
tárolóban tartja konfigurációs adatait, az úgynevezett meta- 
base-ben (lásd tech.net magazin 2001. január, 16. oldal). Ez 
egy memóriában tárolódó adatbázis, mely nagyon gyors 
adatelérést eredményez, ami kritikus a különböző protokollok 
nagyteljesítményű futtatásához. (A metabase.bin állomány 
adja ennek az adatbázisnak a kezdőértékeit rendszerindulás- 
kor, illetve ide íródik ki az adatbázis leálláskor.) Az Exchange 
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A System 


Attendant Service 


ge 2000-ben 


2000 ezzel szemben az Active Directory konfigurációs partí- 
ciójában tárolja a beállításait. Annak érdekében, hogy az IIS 
továbbra is a számára optimalizált metabase-ből tudjon dol- 
gozni és ne kelljen az Active Directory-hoz fordulnia, szüksé- 
ges az AD és a metabase közti adatszinkronizáció. 

Ezt a feladatot látja el a Metabase Update Service (MUS), 
mely kiolvassa a konfigurációs adatokat az Active Directo- 
ry-ból és beírja az Internet Information Services metaba- 
se-ébe. A Metabase Update Service tehát nem külön szol- 
gáltatás, hanem a System Attendant Service alatt fut, fo- 
gadja az Active Directory címtárváltozási értesítéseit, me- 
lyek az IIS keretein belül futó protokollokkal kapcsolatos 
konfigurációs változások hatására generálódnak. Ezen érte- 
sítések alapján automatikusan frissíti az IIS metabase-t. 

A fő jelentősége ennek a szolgáltatásnak, hogy elég bármely 
tartományvezérlőhöz csatlakoznunk az Exchange System Ma- 
nagerrel, és az ott végrehajtott konfigurációs változtatások 
automatikusan érvényre jutnak a megfelelő Exchange 2000 
kiszolgálón ezen szolgáltatásnak köszönhetően, még akkor 
is, ha az adott kiszolgálóhoz nincs is állandó hálózati kap- 
csolatunk. Persze ahhoz hogy ez jól működjön, az Active Di- 
rectory replikációnak megfelelően kell működnie, illetve a 
MUS-nak el kell tudnia érni egy tartományvezérlőt. 

A szolgáltatás működéséből adódóan az is kiderül szá- 
munkra, hogy ha direktben módosítjuk a metabase-t, akkor 
az felülíródik az Active Directory-ban tárolt információk- 
kal, mert a Metabase Update Service az adatokat csak egy 
irányba, az Active Directory-tól a metabase felé frissíti. 
Vajon miért kell erről a komponensről tudnunk? Egyrészt 
azért, mert tevékenységéről az eseménynaplóban bejegyzé- 
seket találunk. Mindazon esemény, melynek forrása az 
MSExchangeMU, az a Metabase Update Service működésé- 
nek (vagy hibájának) a következménye. Másrészt az Ex- 
change 2000 rendszerünk finomhangolásakor jól jön a 
komponens működésének nyomonkövetése. Például, ami- 
kor a fájlrendszerbeli SMTP Mailroot könyvtár tartalmát 
szeretnénk a rendszerpartícióról egy másik meghajtóra 
tenni. Ennek a könyvtárnak az áthelyezésére nincs grafikus 
felület az Exchange System Managerben, még csak ne is a 
Metabase Editor eszközzel kísérletezzünk! Akkor mit is tu- 
dunk tenni a Default Virtual SMTP Server mailroot alatt 
használt mappáinak áthelyezése érdekében? 

Állítsuk le az Exchange szolgáltatásait, többek között a IIS- 
t is. Mozgassuk el a kívánt új helyre az Exchsrvrmailroot 
mappa alól a megfelelő (jelen esetben a VSI 1) mappát és 
összes almappáját. Vegyük elő az ADSIEdit eszközt, és ke- 
ressük meg a konfigurációs konténer következő objektumát: 
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Configuration Containerl CN-Configuration, 
CN-Services, 

CN-Microsoft Exchange, CN-cszervezet?, 
CN-Administrative Groups, 

CN-cadmin csoport, 

CNsServers, 

CN-ckiszolgálóz, 

CN-Protocols, 

CNESMTP, 

CN-1 


(jelen esetben a Default Virtual SMTP Server beállításait 
módosítjuk) . 

Ennek az objektumnak keressük ki a következő attribútu- 
mait és írjuk át a kívánt új elérési útnak megfelelően: 


msExchSmtpBadMailDirectorys 
msExchSmtpPickupDirectory 


msExchSmtpOueueDirectory 


Amennyiben több tartományvezérlőnk van, várjuk meg, 
hogy a címtárreplikáció végrehajtódjon. Indítsuk el a Sys- 
tem Attendant szolgáltatást (benne elindul a Metabase 
Update Service), és várjuk meg a sikeres metabase frissí- 
tést, melyet az eseménynaplóban a 1005-ös események 
jeleznek (forrás: MSExchangeMU, kategória: General). 

Ezzel a címtárbeli adatoknak megfelelően frissült a meta- 
base, indíthatjuk a további Exchange szolgáltatásokat, és 
az SMTP már az új könyvtárakban fog dolgozni. 


Recipient Update Service (RUS) 

Az Exchange 2000-nek nincs saját címtára, hanem a Win- 
dows 2000 Active Directory-ját használja erre a célra. Azaz 
az Active Directory-ban található felhasználói és csoportob- 
jektumok használhatók fel címzésre is. Vajon akkor mit kell 
itt frissíteni egy ilyen szolgáltatással? Az Exchange 2000 
egyszerre több címlistát is tud kezelni. Az egyes címlisták- 
hoz tartozás feltételét egy-egy LDAP lekérdezés határozza 
meg. A levelek címzésére felhasználható objektumoknak van 
egy showlnAddressBook tulajdonsága, mely egy , multiva- 
lue" mező, és ide íródik be mindannak a címlistának a neve 
és helye, amelyeknek az adott objektum tagja. 


CNzAdministrator Properties BEZEz 


Attibutes I Security 













Path: LDAP://emailserv.exchtest.hu/CN sAdministrator CN-Users DCse 


Class: user 
Select which properties to view: [Optional x 
Select a propetty to view: 





Edit Attibute: 


Valuelsj CN:Default Global Address List CNsAll Global Addiess 
CN5AI Users. CN.5All Address Lists. CNsAddress Lists C 










Add Hemove 





a Címlista tulajdonság 
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A másik attribútum - amit ez a szolgáltatás frissít - az ob- 
jektum e-mail címeit írja le. Ezek az e-mail címek leggyak- 
rabban egy Recipient Policy-ban definiált LDAP lekérdezés 
és címminta alapján generálódnak a RUS szolgáltatás által. 

Amikor egy új tartományba telepítjük az Exchange 2000- 
et, vagy olyan tartomány felhasználóinak is akarunk cí- 
mezni leveleket, amelyben nincs Exchange 2000, akkor 
szükségünk van a Recipient Update Service-re egyrészt a 
levelezésbe bevont objektumok címlistához rendelése, 
másrészt az e-mail címek generálása miatt. 

A RUS két módban működik: az egyik a tartomány névteré- 
ben (Domain RUS), a másik az AD konfigurációs névterében 
(Enterprise RUS). A tartománynévtérben a felhasználók és 
csoportok vannak, így a Domain RUS az ezekkel kapcsolatos 
címlistaattribútumok frissítéséért felel. Az Enterprise RUS a 
Store adatbázisért, magáért a System Attendant Service- 
ért, az MTA-ért felel, melyeknek szintén van e-mail címük, 
hogy a különböző Exchange 2000 kiszolgálók egymással 
üzeneteket tudjanak cserélni. Ezek az objektumok az AD 
konfigurációs névterében vannak. 

Ennek a két RUS szolgáltatásnak a működését sürgethet- 
jük a System Managerből, amit a következő ábra mutat. 
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5 Két RUS a System Managerben 


A RUS működéséről információkat kaphatunk, ha bekap- 
csoljuk a diagnosztikai naplózást. Ekkor az MSExchangeAL 
szolgáltatás 8174-es eseménye jelzi a sikeres frissítést. 
Bár egy tartományban több Exchange kiszolgáló is le- 
het, ezek mindegyikében van RUS szolgáltatás, de csak 
egy aktív ezek közül. 


DSAccess Service 

Az Exchange 2000 működése során nagyon gyakran használja 
az Active Directory-t, hogy cím- és konfigurációs információ- 
kat olvasson ki. Ez sok Exchange kiszolgáló és intenzív leve- 
lezési forgalom mellett nagyon leterhelné a tartományvezér- 
lőt és a Globális Katalógus kiszolgálóját, emellett még jelen- 
tős hálózati forgalmat is generálna. Ennek optimalizálása ér- 
dekében hozták létre a DSAccess cache-t. 

Ez a szintén a System Attendant keretein belül futó szol- 
gáltatás az Active Directory lekérdezése során visszaka- 
pott címtárobjektumokat tárolja, és újbóli lekérdezéskor 
már nem a tartományvezérlőtől és a Globális Katalógustól 
A szolgáltatás az inicializáláskor maximum 10 rendelke- 
zésre álló helyi tartományi és telephelyi címtárkiszolgálót 
detektál, melyekhez round robin módszerrel felváltva for- 
dul, hacsak kézzel be nem állítunk számára egyet. 

A konfigurációs adatok lekérdezésére felhasznált tarto- 
mányvezérlőt megnézhetjük a System Manager segítségé- 
vel a kiszolgálónk , General" tulajdonságlapjának alján. 
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EMAILSERY Properties Z 2]x 


Monitoring] FülTestindesing ] 
Diagnostics Logging — ] — Detals 


Policiss  ]  Secuiy] 
General l Locales ] 


Ag EMAILSERV 








Version 6.0 (Build 4417.5) 
TE subject logging and displagi 


En 
TT Epable message tracking 

[7 Logfile maintenance 

] 7 Remove log files ! 


Remove files older than (days) 7 I 








FT Ihis is a hront-end server 
Ciients connect here, and commands are relayed to a back-end servet. 


"Domain controller used by services on this server: 


JEMAILSERV.exchtest.hu 





Cancel ápol, Help 





a Konfigurációs DC neve a kiszolgáló tulajdonságlapján 


A manuális tartományvezérlő és globális katalógus konfigurálá- 
sához a következő registry beállítások állnak rendelkezésünkre: 


Helyi tartományvezérlőhöz: 


HKEY LOCAL MACHINENSysteml 

4  CurrentControlSetlsServicest 

4  MSExchangeDSAccessílProfilesN 

4  DefaultWserDC1 (2, ...) 

IsGC - 0 

HostName - Tartományvezérlő.ceg.hu 
PortNumber - 0x185 (alaphelyzetben) 


Globális katalógushoz: 


HKEY LOCAL MACHINENSystemY 

4  CurrentControlSetlsServicestV 

3  MSExchangeDSAccessíProfilesYV 

4  DefaultWserGC1 (2, ...) 

IsGC 1 

HostName - GlobálisKatalógus.ceg.hu 


PortNumber - 0O0xCC4 (alaphelyzetben) 
Tartományvezérlő a konfigurációs adatok lekérdezéséhez: 


HKEY LOCAL MACHINEXSystemt 

3, CurrentControlSetlsServicest 

Hú, MSExchangepSAccesslinstance0 
ConfigDCHostName - Tartományvezérlő.ceg.hu 
ConfigDCPortNumber - 0x185 (alaphelyzetben) 


A DSAccess a megfelelő Active Directory lekérdezése után 
a kapott adatokat öt percig tárolja, maximum 4 MB terje- 
delemben. A DSAccess cache felhasználásának hatékony- 
ságáról a System Monitor segítségével kaphatunk informá- 
ciót. Mind a tár méretét, mind a tárolási időtartamot tud- 
juk szabályozni, azonban mérlegelni kell, hogy a túl nagy 
tár késlelteti a frissített adatok felhasználását, a túl kicsi 
tár pedig nem növeli a hatékonyságot. 

Ezek alapján a DSAccess gyorsítótárát a következő registry 
beállításokkal hangolhatjuk: 
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HKEY LOCAL MACHINENSystemlCurrentControlsSetN 


4  ServicesiMSExchangeDSAccesslInstanceON 


CacheTTL (REG DWORD) — az adattárolás időtartama 
másodpercben 

MaxEntries — maximálisan tárolt címtárbejegyzések 
száma 

vagy 


MaxMemory — a gyorsítótár maximális mérete kB-ban 


A fentiek alapján tehát mérlegelhetjük, hogy az adattáro- 
lás időtartama mellett melyik korlátozást alkalmazzuk: a 
maximálisan tárolt címbejegyzések számát, vagy a gyorsí- 
tótár méretét. E két beállítás hatását úgy tudjuk összevet- 
ni, hogy a DSAccess memória felhasználása a következő 
képlettel becsülhető: 2.5 MB alapmemória -- 3.6 kB " 
(egyidejű levélterhelés) " CacheTTL 


DSProxy Service 

Nemcsak az Exchange kiszolgálónak van szüksége a címtárak 
elérésére a levelezés során, hanem a felhasználók is lekérdezik 
azt a címlisták nézegetésekor. Ez nemcsak a szándékolt címlis- 
ta böngészéskor valósul meg, hanem minden Outlook üzenet 
írásánál, hiszen az Outlook automatikusan megpróbálja beazo- 
nosítani a ,To" (Címzett) mezőbe írt címzettet az Exchange 
címlistájából, még mielőtt a levelet elküldtük volna. 

Outlook 2000 előtti MAPI kliensek nincsenek arra felkészít- 
ve, hogy ne az Exchange kiszolgálón magán keressék a 
címtárat, így ezen kliensek számára hozták létre a DSProxy 
szolgáltatást. Ez - a nevéből adódóan - a címtárlekérdezé- 
seket a helyi globális katalógushoz továbbítja, majd a vá- 
laszt visszaadja a kérést kezdeményező kliensnek. 

De nem csak MAPI klienseknél működik így a szolgáltatás. 
Amennyiben egy LDAP klienst az Exchange 2000-hez kap- 
csoljuk címtár-információk lekérdezésére, akkor is a DSPro- 
xy fogja kiszolgálni ezeket a kéréseket. 

Ugyanígy, az Outlook Web Access felületet használó, felhaszná- 
lók által generált http formájú címlista-lekérdezéseket az 
Exchange 2000 LDAP-pá konvertálja, és a DSProxy segítségével 
továbbítja a globális katalógushoz, majd a DSProxy-hoz érkező 
LDAP válaszokat html formában továbbítja az OWA klienshez. 
Az Outlook 2000 kliensek alaphelyzetben másképpen veszik 
igénybe a DSProxy szolgáltatását. Az üzenetprofilban nem 
adhatunk meg külön címlista-kiszolgálót, így amikor az 
Outlook 2000 először indul, a profilban meghatározott 
Exchange 2000 kiszolgálótól megkérdezi, hogy melyik a 
globális katalógus kiszolgáló, akihez majd a címlista-lekér- 
dezéseit intézheti. Ez a kiszolgáló beíródik a profilba, így 
innentől kezdve az Outlook 2000 mindig ezt fogja használ- 
ni címlista lekérdezésre egészen addig, amíg az elérhető 
számára. Ha ez a kiszolgáló nem elérhető, akkor az Outlook 
újraindítása után új globális katalógus kiszolgálót kér a 
DSProxy szolgáltatástól, és ezt jegyzi be a profilba. Sajnos 
ez a folyamat csak a globális katalógus elérhetetlensége- 
kor játszódik le, így a helyi globális katalógus leállása ese- 
tén, egy távoli globális katalógusra beálló kliens egészen 
annak elérhetetlenségéig fogja azt használni, ami nem a 
legoptimálisabb helyzet. 
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Ha ez nagyobb veszéllyel jár számunkra, mint az, hogy ezzel a 
folyamattal csökken az Outlook kliensek és az Exchange 2000 
közti kommunikáció, ezt a hivatkozás-átadási folyamatot (re- 
ferral) kikapcsolhatjuk a következő registry bejegyzéssel: 


HKEY LOCAL MACHINElSystemlCurrentControlSett 
4, ServicelMSExchangeSANParameters 


No RFR Service 5 1 


Office XP-nél még nem tudom, hogy hogyan történik ez a 
folyamat, érdeklődők küldjenek e-mail nekem, és ha ad- 
digra kiderítettem azt a problémát, akkor megválaszolom. 


Nem nevesített szolgáltatásként futó SA funkciók 

Az egyik legfontosabb további SA funkció szintén az Acti- 
ve Directory-hoz kapcsolódik. Hogyan is tudunk egy Win- 
dows 2000 AD-beli felhasználót levelezésbe bevonni? Az 
Active Directory Users and Computers eszközzel, egysze- 
rűen elindítjuk az , Exchange Tasks" menüt a felhasználóra 
vonatkozóan, és ott kiválasztjuk például, hogy ,Create 
Mailbox". Vagy kicsit bonyolultabban LDIFDE eszköz segít- 
ségével módosítjuk az adott felhasználó címtártulajdonsá- 
gait, és megadunk neki egy levelező-kiszolgálót. Mindkét 
esetre igaz az, hogy tulajdonképpen nem közvetlenül uta- 
sítjuk az Exchange kiszolgálót arra, hogy hozza létre a le- 
velesládát, hanem csak jelezzük a címtárban ebbéli kíván- 
ságunkat, és a System Attendant fogja ténylegesen létre- 
hozatni a levelesládát. Ugyanígy történik a nyilvános 
mappák levelezésbe bevonása is. 

Egy korábbi cikkemben írtam az Exchange 2000 emelt 
szintű biztonságáról, és ha emlékeznek, ott is szó volt a 
System Attendant szolgáltatásról annak vonatkozásában, 
hogy a felhasználóknak ez a szolgáltatás továbbítja a fel- 
használó-azonosító tokent, és a bizonyítványt. 

Újabb fontos funkció a levelesládák (és nyilvános mappák) 
méretének figyelése és a renitensen leveleiket nem törlő 
felhasználók elleni fellépés. Erre szolgál a kvóták megadá- 
sának lehetősége, mellyel több szinten különböző szigorú- 
sággal járhatunk el a kvótát túllépő felhasználókkal szem- 
ben. Első szinten kapnak egy figyelmeztető levelet, máso- 
dik szinten nem küldhetnek levelet, harmadik szinten nem 
fogadhatnak levelet. Ezeket a ,büntetéseket" is a System 
Attendant szolgáltatás foganatosítja. 


tech.net! 


A SYSTEM ATTENDANT SERVICE AZ EXCHANGE 2000-BEN 


Szintén a levelesládákkal kapcsolatos a törölt elemek két- 
fázisú eltávolítása. Azaz amennyiben be van állítva 0 nap- 
nál nagyobb érték a , deleted items retention time", azaz a 
törölt elemek visszaállíthatósága" paraméterhez, akkor a 
levelek törlésekor azok egy rejtett , szemetesládába" kerül- 
nek, ahonnan az Outlook kliens megfelelő menüje segítsé- 
gével visszaállíthatók. A System Attendant ebből a szeme- 
tesládából üríti véglegesen ki azokat a leveleket, melyek a 
visszaállíthatóságnál beállított napnál régebbiek. 

Szintén System Attendanttal kapcsolatos feladat az üze- 
netek nyomkövetése, illetve az ezzel kapcsolatos naplóál- 
lományok kezelése. Ennek helyét szintén a registryből 
módosíthatjuk is. 


HKEY LOCAL MACHINENlSystemlCurrentControlSetN 
4  ServicelMSExchangeSANlParameters 


LogDirectory - ,Elérési út" 


Az SA levelesládája 

A System Attendant szolgáltatásnak van saját levelesládá- 
ja, mely alaphelyzetben az első levéladatbázisban foglal 
helyet. Ennek ott van szerepe, hogy bizonyos funkciók 
nem működnek, ha ezt az adatbázist leállítjuk. Például az 
Exmerge segédprogramot sem tudjuk akkor futtatni, ha az 
SA levelesláda nem elérhető. 


SA hibafelderítés 

Ha valami problémánk adódik a System Attendant szolgál- 
tatással, akkor érdemes bekapcsolni a kiszolgálónk System 
Managerbeli , Diagnostic logging" tulajdonságlapján a 
diagnosztikai naplózást, mellyel jóval több információ fog 
bekerülni az eseménynaplóba szolgáltatásunk működésé- 
ről, mint alaphelyzetben. (Csak akkor állítható be a diag- 
nosztikai naplózás, ha fut a System Attendant :) !) 


Kérem írják meg, hogy milyen további Exchange-dzsel, 
vagy SharePoint Portal Serverrel kapcsolatos témáról ol- 
vasnának szívesen! 


Soós Tibor (MCSE, MCT) 

soost oigjb.hu 

IOSOFT - John Bryce Oktatóközpont 
www.igjb.hu 
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Rés a pajzson - pajzs a résen? 

Manapság a vállalati számítógéphálózatok vírusfenyegetettsége, 
sérülékenysége az internet felől igen nagy százalékban az e-ma- 
il rendszeren keresztül nyilvánul meg. A levelezőrendszerek — je- 
len esetben az Exchange Server - hatékony vírusvédelme komoly 
kihívást jelentett és még jelenteni is fog jó ideig a szoftvergyár- 
tóknak és a felhasználó vállalatoknak egyaránt. Bizonyos hiá- 
nyosságok sürgős pótlást igényelnek mindkét fél részéről. 

Ezen cikk szerzője nem vállalkozik a lehetetlenre, azaz min- 
den létező Exchange vírusvédelmi megoldás pártatlan be- 
mutatására. Azonban megpróbálok az általános technoló- 
giák és szabályok mellett konkrét termékeket is bemutatni. 
Mivel a Microsoft (még) nem gyárt saját vírusvédelmi szoft- 
vert, a téma más gyártók termékeinek ismertetését igényli. Az 
említett szoftvereken kívül létezik még ezernyi más megoldás, 
amelyek képességeiről nem tudok (vagy nem szeretnék) nyilat- 
kozni. Amit szintén tudatosan hagyok ki: az egyes AV kereső 
és tisztító-motorok (engine) hatékonyságának és felismerési 
képességeinek összehasonlítását. Az [1]-es és [2]-es címen 
található független intézetek megbízható forrást jelentenek a 
víruskergető motorok képességeinek minősítésére. 

Az alábbiakban a témához tartozó Microsoft Tudásbázis 
(Knowledge Base) oldalakra az adott cikk azonosítójával hi- 
vatkozom 0123456 formában. Ezen azonosítók alapján a [3] 
címen lekérdezhetőek a cikkek. A vírusvédelemre a továbbiak- 
ban néha az antivírus szó AV rövidítésével hivatkozom. 


Az Exchange, az Outlook, és a vírusok 

A Melissa és az IloveYou megjelenése óta senkit sem érhet 
váratlanul az Outlook programozhatóságán alapuló féregví- 
rusok gyors terjedése. Ezek tulajdonképpen ún. szociális ví- 
rusok, mivel a felhasználó általános érdeklődésére építve 
(pl. szerelmi vallomás, vagy egy meztelen női test látványa) 
próbálja rávenni a csatolt állomány megnyitására. Az utób- 
bi hónapokban a korábban publikusan elérhető féreggene- 
rátor szüleményei tarolnak (Kurnikova, Homepage, Hybris), 
komoly magyarországi informatikai cégektől is kaptam jó- 
néhányat, nyilván ,tesztelési célzattal"... 

A belső és külső címlistákra továbbterjedő fertőzött csatolt ál- 
lományok azonban könnyebben kivédhetőek, mint a ritkább, 
de az üzenetek testrészében (message body) jobban megbú- 
vó html-script férgek. Míg az előbbieknél a csatolt állományok 
tartalomszűrése is kiegészítő megoldás lehet, a második kate- 
góriában akár az előnézeti ablak használata is fertőzést okoz- 
hat. Ezek ellen az Outlook biztonsági beállításai és javításai 
hatékony védelmet nyújtanak, amelyeket az újabb verziók 
(így az XP is) már tartalmaznak, a korábbi verziókhoz pedig 
letölthetőek. Az Outlook E-mail Security Update (0263297) 
az Outlook 2000 esetében egy központilag, közös mappán ke- 
resztül menedzselhető védelmi komponenst jelent. 

Az Exchange kiszolgálóoldali vírusproblémák eldurvulása 
miatt a Microsoft több saját segédeszközt is kihozott az 
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Server 5.5 és 
2000 vírusvédelme 


Exchange adatbázisok tisztításához. Erre példa az 0224493- 
ben leírt ISSCAN is, amely megadott paraméterek alapján 
képes a féregvírusok üzenet és csatolt állomány hadainak 
kipucolására közvetlenül az Information Store-ból. 

Az Exchange vírusvédelmét a rendszergazdák szemszögéből 
két alaptípusra oszthatjuk: az első a háttérben folyamatosan 
futó, az összes csatolt állományt (és üzenetet) módosításkor, 
megnyitáskor és mozgatáskor megvizsgáló ún. folyamatos 
vagy hozzáférési (on-access) komponens, míg a második az 
ún. igény szerinti (on-demand), manuálisan vagy időzítve 
futtatható teljes ellenőrzés. A második kategóriába tartozó 
kifinomultabb szoftverek rendelkeznek inkrementális ellenőr- 
zési opcióval, hogy a nagyméretű adatbázisokat különböző 
időszeletekben lehessen egyszerűbben vizsgálni. Ezt a kate- 
gorizálást termékenként lehetne finomítani, de tessék csak 
házi feladatnak elolvasni a termékleírásokat. :) 


Az őskortól a jövőig 

Ezen terület történetét az eredeti Exchange Server 5.5 hely- 
zetével kezdem, majd rátérek a Service Pack 3 által beveze- 
tett újdonságokra. Az Exchange 2000 kényelmetlen kezdeti 
helyzetén könnyítő Service Pack 1 is említésre méltó újdon- 
ságokat hoz. Az Exchange kiszolgálóoldali vírusvédelme egy- 
re komolyabb kihívást jelent a Microsoft és az AV gyártók fej- 
lesztőinek egyaránt, mivel az Exchange újabb verziói egyre 
bonyolultabbak lesznek, és az e-mail egyre központibb sze- 
repet kap a napi, üzletileg kritikus munkafolyamatokban. 

Az Exchange 4, 5.0 és 5.5 verzióinál az Exchange 5.5 Service 
Pack 3 megjelenéséig a vírusvédelmi szoftverek az Outlook 
kliensek által is használt , mezei" MAPI felületen keresztül csat- 
lakoztak. Maga az e-mail vírusvédelem a kezdeti Exchange-s 
időkben még nem volt ilyen kardinális kérdés, egy 3,57-es flop- 
pyn keringő bootvírus jellemzőbb formája volt a veszélyeknek. 
Azonban a MAPI-alapú fejlesztések több problémával is 
szembesültek, például a skálázhatósági korlátokkal. Az em- 
berek által vezérelt kliensek (Outlook) MAPI kapcsolatait 
kellett sebességben felülmúlnia a vírusvédelmi szoftvernek, 
hogy még a felhasználó előtt ,érjen oda" a csatolt állo- 
mányhoz, ami bizonyos terhelés felett nem mindig sikerült. 
A széleskörű féregvírus fertőzések, amelyek párhuzamosan 
akár az adott Exchange-felhasználó cég összes postaládáját 
is érintették, végképp falhoz állították a MAPI-alapú AV 
szoftvereket. A skálázhatósági kihívások így azonnal biz- 
tonsági, sérülékenységi problémákká fajulhattak. 


Exchange 5.5 SP3 

Ettől a javítócsomagtól számítjuk az Exchange vírusvédelmi 
ivarérettségét, mivel a Microsoft az SP3-ba beépítette a An- 
tivirus API (AVAPI, vagy máshol Virusscan API, VSAPI, 
0263949) támogatást, mint hivatalos AV csatlakozási 
felületet. Ezután sok AV gyártó átírta termékeit az új csato- 
lási felületre, és a skálázhatósági, sebesség-teljesítményi 
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mutatókkal próbálta rávenni a felhasználókat a frissítésre 
(sokszor teljesen ingyenesen). Sokan azonban az SP3 köve- 
telmény miatt késlekedtek a frissítéssel. A VSAPI egyébként 
összecsapott, áthidaló megoldásként jött létre, amely rövid- 
távon skálázhatóságban és sebességben megoldást nyújtott, 
azonban nem tette elérhetővé se a feladó és a címzett azo- 
nosítását, se az üzenet testének és témájának (message sub- 
ject és body) vizsgálatát, mivel csak a csatolt állományt ad- 
ta át az AV szoftvernek. Az AV gyártóknak egyedi megoldást, 
segédprogramokat kellett írni a feladó és a címzett azonosí- 
tásához, az üzenetek testében található html script víruso- 
kat pedig kizárólag igény szerinti szkenneléskor tudták ér- 
zékelni. Az SP4 jónéhány stabilitási problémát kijavított a 
VSAPI implementációkon, de új funkciókat nem vezetett be. 
Az Exchange 2000 megjelenésekor elődjének összes vírus- 
védelmi hiányosságával rendelkezett. VSAPI és MAPI alapú, 
kombinált (választható) elérésű termékek jelentek meg a 
piacon, pl. a Symantec NAV for Exchange és a McAfee 
GroupShield for Exchange szoftverei. Ezek az adott környe- 
zeti problémákból eredő hiányosságokkal rendelkeznek, pl. 
képtelenek az Outlook Web Access-en (OWA), az IMAP és 
POP3 klienseken keresztül kezelt csatolt állományok el- 
lenőrzésére (0286638), valamint nem tudnak a kimenő 
SMTP forgalommal mit kezdeni. Súlyosabb esetben a köz- 
vetlen bejövő SMTP forgalom is átsétál rajtuk, amelyet pl. 
a McAfee egy külön kiegészítő SMTP szkenner programocs- 
kával hidalt át. A Symantec azt javasolja, hogy Exchange 
2000 az SP1 megjelenéséig ne legyen közvetlen SMTP foga- 
dó, hanem előbb egy dedikált SMTP kapugépen történjen 
meg az Exchange-független szűrés (amely szintén mehet 
NAV termékkel) . Nemcsak ezen szoftvergyártók saját fejlesz- 
tési bukdácsolásainak köszönhetőek a jelenlegi Exchange 
2000-hez készült AV szoftverek korlátai, hanem az adott il- 
lesztési felület fejlesztését halogató Microsoftnak is. 

A jelenlegi, SP1 nélküli implementációk (és általában bármi- 
lyen vírusvédelem) alapvető teszteléséhez javasolt az EICAR 
tesztállomány, amely a [9]-es címről szedhető le. Ha különbö- 
ző kliensekkel (Outlook, OWA, IMAP4) csatolt állományként 
küldjük-fogadjuk, a lehetséges lyukakat hamar megtalálhatjuk. 
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5 VSAPI hiányosságok ala McAfee (Se feladó, se cím- 
zett, se tárgy. Ez nem is csoda egy 1970-ből származó 
levél esetén :) 
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Exchange Server 2000 SP1 

A MAPI funkciógazdagságát a VSAPI sebességével és ská- 
lázhatóságával kombináló VSAPI 2.0 jelenti a korrekt 
megoldást az égető AV problémákra. A VSAPI2 az alábbi 
funkciókat is támogatja majd: 

2 hozzáférés a feladó és a címzett paramétereihez 

a feladó és a címzett figyelmeztetése levélben 
hozzáférés az üzenet tárgyához (subject), szűrés tárgy 
alapján 

az üzenet testének ellenőrzése (message body) 
mindkét irányú SMTP forgalom ellenőrzése 

OWA védelme 

az M: meghajtó kezelése 

kiválasztott postafiókok és közös mappák kizárása az 
ellenőrzésből 

A SP1 megjelenése után közvetlenül elérhető lesz a Syman- 
tec NAV 2.5 for Exchange 2000 és a McAfee GroupShield 
5.0 for Exchange 2000, amelyek az előbbiekben felsorolt 
teljes funkcionalitással rendelkeznek majd, ezáltal eljön 
majd a tejjel-mézzel folyó Exchange vírusvédelmi Kánaán. 
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A harmadikutas megoldások 

Az eddig részletezett MAPI és VSAPI megoldásoktól radiká- 
lisan eltérő elven működik a Sybari által készített termék. 
Az Extensible Storage Engine (az Information Store szíve) 
nem dokumentált elérésével, cseréjével egy jól működő, de 
a Microsoft által hivatalosan nem támogatott megoldás 
jött létre. A status guo-t a Microsoft Tudásbázis 0250500 
cikke teremti meg, amely leírja, hogy a Microsoft Premier 
támogatást (PSS) igénylő ügyfeleknek hogyan kell ideigle- 
nesen letiltani az ESE piszkálását. A MAPI és az AVAPI 
gyermekbetegségeit nélkülözi, a vírusokat az üzenetek 
testrészében is el tudja kapni, akár az OWA-n keresztül is. 
A Sybari szoftvere a víruskereső-motor szempontjából nyi- 
tott, az Exchange 5.5 és 2000 használatakor is jónéhány 
ismert gyártó motorjával tud együttműködni (NAI, Sophos, 
Norman, CA). Esetében jobban oda kell figyelni azonban az 
Exchange hotfixek és patch-ek telepítésénél, mivel azt 
egyesével tesztelnie kell a Sybarinak, ami potenciális kés- 
leltetést jelenthet más biztonsági lyukak betömésénél. 
Ezen ,egyedi" megoldás életképességét jelzi, hogy idén 
márciusban a Trend Micro is megjelent egy ESE-alapú ter- 
mékkel, amely viszont (az általam hozzáférhető informá- 
ciók alapján) csak az 5.5-ös verzióval kompatibilis. 


Potenciális öngól(ok) 

Ha egy adott kiszolgálógép az Exchange futtatása mellett 
állomány-kiszolgálóként is funkcionál (pl., SBS), akkor a 
vírusvédelmi szoftverünk állománykiszolgálót védő kompo- 
nense galibákat okozhat, ha nem jól konfiguráljuk. Ez ál- 
talánosan vonatkozik minden tranzakcionális adatbázis- 
szoftverre (tehát pl. az SOL-re is), mivel a komoly méretű 
adatbázisok és logjaik folyamatos vírusvédelmi abajgatása 
a teljesítményre komoly kihatással lehet. Most azonban 
térjünk vissza az Exchange-hez: a vírusvédelmi szoftve- 
rünkben a háttérben állandóan futó komponensre, és az 
időzített szkennelésre vonatkozó beállítások között 
egyaránt keressük meg a ,kivétel(exclude)" paramétert, és 
az Exchange összes fontos könyvtárát (az SMTP kjú-t, az 
adatbázisokat és logokat) vegyük bele, az M: meghajtóval 
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együtt. Ellenkező esetben a beérkező e-mail vírusos csatolt 
állományát az állományrendszer vírusvédelme ,előzéke- 
nyen" kiszűrheti, az Exchange lelki világát meggyötörheti, 
vagy az M: meghajtó piszkálása esetében az adatbázist is 
megsértheti (0298924). Az a tény, hogy ugyanattól a gyár- 
tótól származik az Exchange és az állománykiszolgálás ví- 
rusvédelme, még nem ad automatikus felmentést ezen kon- 
figurálási teendők álól. Állítólag lassacskán a gyártók már 
erre is elkezdtek odafigyelni... 

A jelenleg elérhető (a cikkben említett összes) Exchange AV 
szoftver általában rendelkezik a csatolt állományok kiterjesztés 
alapján történő tartalomszűrésének funkciójával. Mivel a po- 
tenciálisan veszélyes csatolt állománytípusokat (exe, vbs, bat, 
pif, stb...) automatikusan karanténba helyezhetjük, máris nem 
kell a klisésebb vírusoktól tartanunk. Ez a grafikus kezelőfelü- 
letből paraméterezhető lehetőség sokszor erősebb védelmet 
biztosít, mint a napi frissítésű vírusvédelmi adatbázis és motor. 
A Symantec NAV esetében ezt a regisztrációs adatbázisban kell 
paramétereznünk, de nekik van külön tartalomszűrő szoftverük, 
a Mail-Gear. A GFI által gyártott Mail Essentials for Exchange a 
tartalomszűrés egyik nagymestere, itt a vírusvédelem mellett 
(html scriptet is kiszedi az üzenet testrészéből) felhasználónként 
definiálhatjuk a tiltandó kiterjesztéseket, vagy az üzenetek 
tárgymezőjét (pl. ILOVEYOU). A Trend a Scanmail for Exchange 
E-Manager nevű szoftverével egészíti ki a vírusvédelmi funkció- 
kat. A McAfee által kifejlesztett Outbreak Manager komponens 
(a GroupShield része) a tömeges, hasonló csatolt állományok 
viselkedése, mennyisége alapján tud eszkalációs útvonalon vé- 
gigmenni, akár az Exchange leállításáig. 

Ha nagy rendelkezésreállású, fürtözött Exchange rendszer- 
hez keresünk vírusvédelmet, körültekintően vizsgáljuk meg 
az egyes termékeket, mert nem magától értetődő, hogy 
minden szoftver rendelkezik MS fürtözési támogatással... 
Vannak bizonyos szoftverek, melyek csak aktív-passzív pá- 
rosítást tudnak lekezelni jelenleg, de az aktív-aktív üzem- 
mód támogatása is elérhető már jónéhánynál. 


Ez a harc lesz a végső... 

Mint azt a szerteágazó veszélyforrások tárgyalása is mutatja, 
egyszerű, egyklikkelős megoldás nincsen. Javaslom hogy min- 
denki rendszeresen látogassa az általa használt vírusvédelmi 
szoftver gyártójának támogatási weboldalát, és a Microsoft Tu- 
dásbázist. Exchange verzióváltás vagy SP telepítés előtt pedig 
körültekintően tájékozódjon az elérhető termékek képességei- 
ről, és ne sajnálja az időt tesztrendszer kialakítására sem. 

Az Exchange 2000 bevezetése megfelelő vírusvédelem nél- 
kül komolyan veszélyeztetheti a projektet és a teljes háló- 
zatot is, ezért tanácsolom hogy kizárólag az SP1 és az arra 
épülő vírusvédelmi szoftverekkel együtt kezdjünk bele, vagy 
vállajuk az összetettebb megközelítést, esetleg a , harma- 
dikutas" megoldást. 

Ne feledjük, hogy a legtöbb AV gyártó előfizetéses alapon, 
adott időszakra biztosítja a legfrissebb programverziók 
használati jogát. Éljünk ezen lehetőséggel rendszeresen 
(küldik CD-n, vagy letölthető jelszóvédett weboldalról) , és ne 
csak az adatbázisokat és motorokat frissítsük, mivel a köz- 
tes, 0.01 verziókülönbségnyi frissítések is megkönnyíthetik 
az életünket. A különböző termékek teszteléséhez pedig a 
gyártói weboldalakon vagy a helyi képviseleteknél, forgal- 
mazóknál elérhetőek a 30 napos próbaverziók. 
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És 2000 VÍRUSVÉDELME 


A cikk végére egy pontokba összefoglalt kis tanácsgyűjte- 
mény jutott (Vírusvédelmi harcosok Exchange kiskátéja), az 
eddig figyelmesen olvasók átugorhatják. :) 

"2 A konfigurálásnál a belső riasztásokat megfelelő helyre 
irányítsuk: pl e-mail SMS-en keresztül a rendszergazda 
GSM készülékére. 

Kérjünk az AV gyártóktól e-mail riasztást a súlyosabb 
víruskitörések esetében (a weboldalaikon lehet kérni). 
Ne szégyelljünk több gyártó termékeit kombinálva használni. 
0 A vírusvédelemnek mindenütt jelen kell lennie (kiszol- 
gálók, munkaállomások, web-proxy). 

Használjuk mindig a legfrissebb verziójú programot (ne 
csak adatbázist és motort frissítsünk!) . 

0 Az Exchange vírusvédelme a csatolt állományok és html 
scriptek tartalomszűrésével kombinálva hatékonyabb 
(exe, vbs, htm, pif, stb). 

A felhasználók oktatása ezen a területen is szükséges, 
de nem mindenható. 

"b Rendszeres (havi) tesztelés az EICAR tesztállománnyal, 
amely a [9]-es címről letölthető. Ha az Eicar-t sem tudja el- 
kapni a védelem, akkor valószínűleg az éles vírusokat sem... 
Legyen naponta, vagy naponta 2x automatikusan fris- 
sítve a vírusvédelmi adatbázis az interneten keresztül. 
Figyeljünk oda az apróságokra: pl. a kombinált szerepkö- 
rű kiszolgálóknál a konfigurációs ütközésekre. 

Az Exchange védelme csakis átfogó IT biztonságpoliti- 
ka részeként ér valamit. Ne sajnáljuk a pénzt szakem- 
ber, specialista megbízására, ha házon belül nincs meg- 
felelő emberi erőforrás. 

Legeslegutoljára pedig a gyártók weboldalainak címe meg- 
található a [4] és [8] közötti URL-eken. 


(A szerkesztő megjegyzése: Az Event Sink-ek segítségével a 
W2K/E2K megjelenése óta elfogható, módósítható, eltéríthető 
a kiszolgálón áthaladó összes SMTP levél, még a belső levelezés 
is. Hogy ez a vírusírtók gyártóinak miért nem jutott eszébe?...) 


[mick] 


Radvánszki Gábor, MCP 
gabor(oradvanszki.net 


A cikkben szereplő URL-ek: 
[1] http://www.virusbtn.com/ 
[21 http://agn-www.informatik.uni-hamburg./vtc/ 
[3] http://search.support.microsoft.com/kb/c.asp 
[4] http://www.symantec.com http://www.sarc.com 
[5] http://www.mcafeeb2b.com http:/ 
4 /www.avertlabs.com 
[6] http://www.gfi.hu 
[7] http://www.virusbuster.hu /Sybari/ 
[8] http://www.antivirus.com /Trend Micro/ 
[9] http://www.eicar.org/anti virus test file.htm 
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Transformation 
Services (DTS) 


A DTS funkciója 

Napjaink vállalatainál még mindig rengeteg formátumban tá- 
rolódnak az üzletileg fontos adatok. Bármilyen logikus is len- 
ne, hogy minden adatot relációs adatbáziskezelőben (termé- 
szetesen: SOL Serveren :) ) tároljunk, a helyzet sok helyen 
egyelőre inkább a kaotikus adattárolási , modell" jegyeit vi- 
seli magán. Nemcsak hogy a clipperes programok nem haltak 
ki egészen, de a rendkívül flexibilis MS Access csábításának 
engedve egyre-másra születnek vállalati adatbázisszigetek. A 
szétszórva található adatok elemzése lehetetlen lenne, ha 
nem tudnánk azokat összegyűjteni egy központi adatraktár- 
ban. Sőt! Nemcsak gyűjtögetésről van szó. Sok esetben a 
skaotikus modell" következményeinek elhárítása nélkül sem- 
mit sem ér az adatok központba cipelése - az adatokat az 
elemzéshez egységes formátumra kell hozni! 

A Data Transformation Services pontosan a fenti feladatok 
elvégzésére való. Tetszőleges adatforrásból tetszőleges cél- 
adatbázisba képes adatokat mozgatni, s eközben tetszőle- 
ges adatátalakítást (transzformációt) végezhet. 





Transzformáció(k) 

















Adatforrás OLEDB pi DTS EDS p-] Céladatbázis 


























5 A DTS működésének vázlata 


A DTS először az SOL Server 7.0 verziójában jelent meg. Az 
SOL Server 2000-beli DTS bővebb szolgáltatásokat és rész- 
letesebb dokumentációt tartalmaz. Ez a cikk az SOL Server 
2000 DTS lehetőségeiről szól, de a leírtak nagy része a ko- 
rábbi verzióra is igaz. A DTS alapjaival egy hosszabb cikk- 
sorozatban foglalkozunk majd. 

A DTS elsődleges célja az adatok kiolvasása (egy OLE DB 
adatforrásból), átalakítása, és írása (egy másik OLE DB 
adatforrásba). Ezt a funkciót szokás az ETL (Extract Trans- 
form Load) betűszóval rövidíteni. Az adatpumpa funkció 
mellett a DTS sok egyéb feladattípust tartalmaz, a gyako- 
ribb feladatok listáját a következő táblázat tartalmazza: 


DTS Task Funkció 
File Transfer Protocol FTP letöltés 
ask. 


ActiveX Script Task 


Adatpumpa és transzformáció 

két adatforrás ki 
Tetszőleges alkalmazás 

MEGKENATLatÁS a sssászzzgr 
SOL parancsok végrehajtása 











Execute Process Task 


"Execute SOL Task 
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Data Driven Ouery Task . A bemenő adatok által vezérelt 





Copy SOL Server SOL Server objektumok 
Objects Task másolása, SOL Server 

adatbázisok ki 
"Email küldés 











Benda] 





Beágyazott DTS csomag(ok) 
végrehajtása 


"Execute Package Task 


A DTS részei 

A DTS egy COM objektumokra épülő szolgáltatás az SOL 
Serverben. A DTS komponensek listáját a Developer Edition 
telepítő CD-n található redist.txt fájl tartalmazza. 

Az SOL Serverrel szállított DTS alkalmazások az Import/Ex- 
port varázsló, a grafikus DTS csomag szerkesztő, a DTSRun.exe 
parancssori végrehajtó és ennek grafikus változata, a 
DTSRunUI.exe. A DTS csomagok ütemezett végrehajtását 
az SOL Server Agent végzi. 


A DTS csomag mindig annak az NT fióknak a jogosultsá- 
gával fut, aki a futtatást végzi. Ha a varázslóval, vagy a 
grafikus szerkesztővel futtatjuk a csomagot, akkor a fut- 
tatást végző felhasználó jogai érvényesek. Ha az SOL Ser- 
ver Agentre bízzuk a csomag futtatását, akkor az SOL 
Server Agent Startup Account jogosultságaival hajtódik 
végre. Gyakori hibaforrás, hogy az SOL Server Agent helyi 
System" fiókkal van indítva, így a távoli gépek megosz- 
tott mappáihoz nincs hozzáférési joga! 


Első DTS csomagom 

Valahányszor az Import/Export varázslót futtajuk, DTS cso- 
magot hozunk létre. A varázsló utolsó lépéseinek egyikében 
dönthetünk, hogy az elkészített csomagot megőrizzük, vagy 
futás után eldobjuk. Az utóbbi az alapértelmezett működés. 
A következő ábra a mentési opció bekapcsolását mutatja: 


44. DTS Import/Export Wizard, HEZ 2 





Save. schedule. and replicate package 
Speciíy í you want to save this DTS package. You may also repícate the data or ég 
Schedule the package to be executed at a later time. 














Tán ez Ét 


ITT Run immediately FT Use 


estínation data 





IT Schedule DTS package for later execution El 




















r Save: 
Fémes Esz s 0 te 
€ SOL Server Meta Data Services 
€ Structured Storage File 
C Visual Basic File 
c Back Next; Cancel Help 


o A varázsló által készített DTS csomag mentése 
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A csomagot menthetjük SOL Serverre (az MSDB adatbázis- 
ba), a Meta Data Services (repository) alá, operációs rend- 
szer fájlba és Visual Basic programként. 

Az első két esetben a csomag a Local Packages, illetve a 
Meta Data Services Packages alatt jelenik meg az SOL Ser- 
ver Enterprise Managerben. 

5 CI Data Transformation Services 





Meta Data 


Az operációs rendszer fájlba mentett csomagokat a Data 
Transformation Services csomópontra jobb-kattintás után 
megjelenő menü Open Package pontjával nyithatjuk meg. A 
Visual Basic fájl felhasználásához a Visual Basic 6.0 szükséges. 


Az SOL Server 7.0 esetén a csomagot közvetlenül nem 
tudjuk VB formátumban menteni. Az SOL Server 7.0 te- 
lepítő CD-n, a Idevtoolsjsamplestdts mappában talál- 
ható a DTSDEMO.EXE (önkibontó) állomány. Ez tartal- 
mazza a ScriptPkg.vbp projeket. A ScriptPkg program 
segítségével tudunk SOL Serveren tárolt DTS csomagok- 
ból VB kódot generáltatni. 


A DTS csomag részei 

A DTS csomag lépésekből áll. A lépéseket precedenciasza- 
bályok kapcsolják össze. A lépések hajtják végre az egyes 
feladatokat (task-okat). A varázsló és a grafikus szerkesztő 
az egyes feladatokhoz automatikusan létrehozzák a lépése- 
ket. Az alábbi csomag két lépést tartalmaz. 





[í6kk - [2:0TS Package: dbase2sal) 
[ta Gonsoa  Yöndom . tieb 





Bachaga Ed  Cgrnacton Isk Wotfwr [d d9/:MDA Dan] r s 999 


sss] 


Connection 1 








i 


Bok 


Create Tablel[tem... 


0 


Connection 2 


don 


SCO9oPtt 


a 
8 
6 
a 
Task 
8 

e 
ga 
A 

úg 
na 
A 


9 
ma 
a 
g 
nm 
a 
al 


a A DTS lépések különböző alakban ,,materializálód- 
hatnak"! 


Az első lépés (Create Table, 0 ikon) egy SOL feladatot hajt 
végre. Ha az első lépés sikeres, következik a második (O 
nyíl), amely a Connection1 és a Connection2 OLE DB adat- 
források között végez adatmozgatást (és esetleg adatátala- 
kítást). A lépések kapcsolata lehet , Completion" ,Success" 
és ,Failure" precedencia szerint. Az utóbbi kettő (sikeres, 
sikertelen) alapján elágazásokat készíthetünk. 


A DTS csomag szerkesztése, az adatpumpa 

A DTS csomagok szerkesztésére, és új csomagok kialakításá- 
ra szolgál a Package Editor. A varázsló által létrehozott cso- 
magokat a Package Editorban átalakíthatjuk, vagy új csoma- 
gokat hozhatunk létre. A fenti csomagban a Connection1 és 
Connection2 közötti szürke vonalra duplakattintva megjele- 
níthetjük a Transform Data Task Properties ablakot. 
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A varázsló által készített egyszerű oszlopmásolás transzfor- 
mációt törölhetjük, és új transzformációkat hozhatunk létre 
- akár oszloponként különbözőket. Új transzformáció létre- 
hozásához először kijelöljük a forrás- és céloszlopokat, majd 
a New nyomógombra kattintva választhatunk a felajánlott 
lehetőségek közül. Íme néhány átalakítási lehetőség: 


Transzformáció Funkció 


ActiveX Script Script parancsok végrehajtása 
Copy Column Egyszerű másolás 

Date Time String Dátumformátum átalakítása 
Lowercase String Szöveg kisbetűsre konvertálása 











Az ActiveX Script a legrugalmasabb átalakítási lehetőség, de - 
érthetően - a leglassabb is. Egyszerű átalakítások esetén célsze- 
rű a többi lehetőség közül választani. 

Scriptet készíthetünk VB Script, vagy Jscript nyelven, illetve 
bármely script nyelven, amelynek motorját telepítettük. 

A scriptszerkesztő egy identikus transzformációt generál az álta- 
lunk válsztott nyelven (például, VB Script esetén a következőt) : 


VRRERERERKEKE KKN e kkkktkkkkekkkkkkkkk 
" Visual Basic Transformation Script 
Vakkkkktkkkekekkkekkkekkkkkkkkkkkkkkk 
"Copy each source column to the destination column 
Function Main() 
pDTSDestination("ID") - DTSSource("ID") 
DTSDestination ("COMPANY") 5 DTSSource ("COMPANY") 
DTSDestination( CONTACT") - DTSSource("CONTACT") 
Main - DTSTransformStat OK 
End Function 


A DTSSource és a DTSDestination gyűjtemények az éppen fel- 
dolgozott sor be- és kimenő mezőit teszik elérhetővé. A 
script alapértelmezésben minden beolvasott sorra lefut, és 
egy kimenő sort hoz létre. Ezt a viselkedést befolyásolhatjuk 
a függvényérték módosításával. Például, ha a bejövő sor me- 
zőit külön sorba akarjuk tenni (mintegy , felrobbantani" a be- 
jövő rekordot) egy kimenő oldali táblában, amely egyetlen 
col" oszlopot tartalmaz, a következő scriptet használhatjuk: 


Function Main() 
if DTSGlobalVariables("c").value-0 or 
3, DrTSGlobalVariables("c").valuezz 3 then 
DTSGlobalVariables("c") .value-1 
DTSDestination("col") - DTSSource("ID") 
Main - DTSTransformStat SkipFetch 
elseif DTSGlobalVariables("c").value-1 then 
DTSGlobalvariables ( "c" ) .value-2 
DTSDestination("col") - DTSSource( "COMPANY" ) 
Main - DTSTransformStat SkipFetch 


else 





DTSGlobalvVariables("c") .value-3 
DTSDestination("col") - DTSSource( CONTACT" ) 
Main - DTSTransformStat OK 

end if 

if isnull(DTSDestination("col").value) then 

b Main - Main 4 DTSTransformStat Skipinsert 


End Function 
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A DTSTransformStat SkipFetch hatására a következő sor 
beolvasása helyett ismét az aktuális sorra fut le a transz- 
formáció. A DTSTransformStat SkipIlnsert megtiltja a ke- 
letkezett sor kiírását a fogadó táblába. (Esetünkben a 
NULL kiírását akadályoztuk meg a segítségével.) 

A példascript érdekessége még a ,c" globális változó haszná- 
lata. A globális változók lehetővé teszik az adatcserét egy 
csomag különböző feladatai, illetve egy külső csomag és az 
általa hívott csomagok között. A DTSRun futtatókörnyezet hí- 
vásakor a globális változóknak értékeket adhatunk, így a cso- 
mag végrehajtását paraméterezhetjük. A globális változókra a 
DTSGIobalVariables gyűjteményen keresztül hivatkozhatunk. 


Paraméterezett DTS csomagok 

Ha elkészült egy csomag, amely egy fájl tartalmát egy SOL 
Server táblába másolja, gyakori igény, hogy különböző fájlok 
esetén, illetve más SOL Serverekre is használható legyen. A 
globális változók használatával a csomag paraméterezhetővé 
tehető, a következőképpen. Először adjunk a csomaghoz egy 
ActiveX Script Taskot. Legyen az ActiveX Script Task a cso- 
mag elsőként végrehajtott lépése, az alábbi ábra szerint: 






Connection 1 


A s 


ActiveX Script Tas... 


create Table (tem... 





Connection 2 


Ezután a csomag üres részére jobb-kattintva megjelenő 
menüből a Package Properties menüponttal megjelenít- 
hetjük a DTS Package Properties ablakot. Ennek második 
fülében négy globális változót definiálunk: 


DTS Package Properties: dbase2sal Hz 21 





General . Global Variables ] Logging ] Advanced] 


Add, edít, or delete global variables Írom the DTS package. You 
can access these variables Írom any sciipt in the DTS package. 


Variables: 






select ID. COMPAN, 


tempdb 


A DTS csomagban az elsőként végrehajtódó ActiveX Script 
Task a globális változók alapján állítja be a bemenő fájl 
helyét, a bemenő lekérdezést, a kimenő táblát tartalmazó 
SOL Server nevét és az adatbázis nevét. 

(A ciSSS tartalma a következő lekérdezés: select ID, 
COMPANY, CONTACT from CUSTOMER) 

Az ActiveX Script Task tartalma a következő függvény: 


Function Main() 
dim oPkg, oTask 
:" mutató a DTS csomagra 
set oPkg - DTSGlobalVariables.Parent 
" mutató a módosítandó feladatra 
set oTask - oPkg.Tasks("Copy Data from CUSTOMER 
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4 to [tempdbj] .[dbo)] . [CUSTOMER] Task") 


" bemeneti adatforrás beállítása 


oPkg.Connections("Connection 1").DataSource 
4  DTSGlobalVariables("c1").Value 


" bemeneti lekérdezés beállítása 


oTask.Properties ( "SourceSOLStatement" ) .Value 
tt  DTSGlobalVariables("c1SSS").Value 


" kimeneti SOL Server név beállítása 


oPkg.Connections("Connection 2").DataSource 

4  DTSGlobalVariables("c2").Value 

:" fogadó adatbázis beállítása 

oPkg.Connections ("Connection 2").Catalog -— 
4  DTSGlobalVariables("c2DB").Value 

set oPkg - Nothing 

set oTask - Nothing 

Main - DTSTaskExecResult Success 


End Function 


A fenti kód érdekessége a DTSGlobalVariables.Parent hasz- 
nálata. A Parent tulajdonság magára a DTS csomagra mu- 
tat. Így, miután az oPkg értéket kapott, szabadon mozog- 
hatunk a teljes csomagban. 

A csomag bemenete egy dBase fájl. Ennek helyét a ,Con- 
nection 1" kapcsolat , DataSource" tulajdonsága határozza 
meg. A dBase fájl neve a transzformációs feladat ,Sour- 
ceSOLStatement" tulajdonságában megadott lekérdezés 
from" záradékában található. 

A kimeneti oldalon csak az SOL Server és az adatbázis ne- 
vét állítottuk be - feltételezve, hogy mindig ugyanabba a 
táblába fogunk beolvasni. 

A csomag globális változóit futtatáskor módosíthatjuk. A 
következő DTSRun parancs a /A kapcsoló segítségével ad 
értéket a csomag globális változóinak: 


DTSRun /S (local) /E /N dbaseZsal /A"c1:8-c: temp" 
/A"CISSS:B8zselect ID, COMPANY, CONTACT from 
CUSTOMER" /A"c2:85(local)" /A"Cc2DB:8Bztempdb" 


A globális változó neve utáni ,,:87 a változó típusát, ese- 
tünkben a string típust jelzi. 

A DTSRun használatát részletesen ismerteti a Books Onli- 
ne ,dtsrun utility" című fejezete. 


A DTS csomag szerkezetének felderítése 

Honnan tudhatjuk, mit és hogyan kell módosítani egy DTS cso- 
magban? Az egyik megoldás, hogy a csomagot Visual Basic for- 
mában elmentjük, és tanulmányozzuk a keletkező kódot. Köz- 
ben időnként érdemes beleolvasni a Books Online-ba. A másik, 
talán egyszerűbb lehetőség a Disconnected Edit használata. 

A Package Editorban a Package menüből indítható a Dis- 
connected Edit, amely jól mutatja a csomag szerkezetét, 
és a csomag módosítására is használható. (Vigyázat! A 
Disconnected Edit hasonló a regedt32-höz: nagyon haté- 
kony eszköz, de helytelen használatával a csomag könnyen 
működésképtelenné tehető.) 


Beágyazott és mestercsomagok 

Egy adatraktár feltöltéséhez általában több bemenő adat- 
forrásból kell adatot nyernünk, és több táblába kell adat- 
sorokat írnunk. Vannak párhuzamosan végrehajtható lépé- 
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sek, de vannak esetek, amikor fontos, hogy egy, vagy több 
feladat végrehajtódjon, mielőtt a következő lépés elindul. 
Készíthetünk egy nagy csomagot, ami az egész feltöltési 
folyamatot elvégzi, vagy több, kissebb DTS csomagot, 
amelyeket egy mestercsomag hajt végre. 

Beágyazott DTS csomagok hívására az Execute Package 
Task szolgál. Az Execute Package Task fő paramétere a 
végrehajtandó csomag neve: 





E: 2 
General ] Inner Package Global Variables ] Outer Package Global Variables ] 


Execute Patkage Task Properties 


[ g You can execule a DTS Package using Execute Package task. 





Desciiption ÉVUTETETETEEE 
Location SOL Server 1] 
Package namer [docsezsg 2] Password [8 
Package ID: (39909478-.0EA2-43EC-A854-SOACSOCZIBAB) 


Megadhatjuk továbbá a végrehajtandó csomag globális vál- 
tozóinak értékét (Inner Package Global Variables) és expor- 
tálhatjuk, elérhetővé tehetjük a külső csomagban definiált 
globális változókat a belső csomag számára (Outer Package 
Global Variables). Az utóbbi lehetőség kényelmes paramé- 
tercserét tesz lehetővé a külső és a belső csomag között. 


Ciklusszervezés 

Olykor szeretnénk egy DTS csomag egyik lépését többször, 
ciklusban végrehajtani. Ezt a DTS futtató ,becsapásával" ér- 
hetjük el. Ha egy, már végrehajtott lépés végrehajtási állapot 
tulajdonságát (ExecutionStatus) DTSStepExecStat Waiting ér- 
tékre állítjuk, akkor a DTS a lépést újra végre fogja hajtani. 

A következő példában beágyazott csomagot és ciklusszer- 
vezést használunk arra, hogy egy belső csomagot egy map- 
pa minden fájljára végrehajtsuk. 

A belső csomag (az egyszerűség érdekében) egyetlen Acti- 
veX Script Task-ból áll. Az script a következő: 


Function Main() 
MsgBox DtsGlobalVariables("file").Value 
Main - DTSTaskExecResult Success 


End Function 


A ,file" globális változót nem a belső csomagban definiál- 
juk, hanem a külső csomagból exportáljuk. Látszik, hogy 
ez egy tesztcsomag - hiba lenne felhasználói akciót kezde- 
ményezni (üzenetet küldeni) egy olyan DTS csomagban, 
amit esetleg az SOL Server Agent hajt végre, mert nem je- 
lenne meg a felhasználói felületen az az üzenet, amelyre 
OK-t kell(/ene) nyomnunk! 

A külső csomag a következő feladatokat tartalmazza: 


AB Té 


Exec Inner Package Loop 





Első file 
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Az ,Exec Inner Package" feladat a belső csomagot hívja és 
exportálja a , file" globális változót. 

Az ,Első file" feladat a , file" globális változót feltölti a 
c:(temp mappa egyik fájljának nevével. (Erre a feladatra a 
Scripting. FilegystemObject" és ugyanaz a technika használ- 
ható, amit az alábbi, , Loop" script mutat.) 

A ,Loop" script a következő: 


Function Main() 
Dim fs, f, fi, 
Set fs — 


fc, oPkg 
CreateObject 
t,  ("Scripting.FileSystemoObject") 
Set fl s 
4  (DtsGlobalVariables("file").Value) 
f1.Delete 


fs.GetFile 


" a már feldolgozott fájl törlése 
Set f - fs.GetFolder("C:Vtemp") 
Set fc -— f.Files 
if fc.Counts0 Then 
For Each fl in fc 
DtsGlobalVariables("file").Value -— 
4 "e:(templ" § f1l.Name 
exit for  " az első fájl után kilépünk 
Next 
Set oPkg - DTSGlobalVariables.Parent 
" megismételtetjük az előző lépést, 
" az új paraméterrel 
oPkg.Steps("DTSStep DTSExecutePackageTask 1"). 
4  ExecutionStatus 5 DTSStepExecStat Waiting 
End If 
Set fs - Nothing 


Set f 


Nothing 
Set f1l 5 Nothing 
Set fc 5 Nothing 
Set oPkg - Nothing 
Main - DTSTaskExecResult Success 


End Function 


A DTS tulajdonképpen egy fejlesztési platform. Lényegesen 
több, mint amit ebben az írásban el tudtam mondani. Töb- 
bek között, nem esett szó a testreszabott DTS feladatok 
készítéséről, illetve a többfázisú adatpumpa használatáról. 
Ezek, és sok egyéb információ részletesen, példákkal il- 
lusztrálva megtalálható a Books Online-ban. 


Kószó Károly 
rendszermérnök 
karolyk microsoft.com 





[ia LPIA Er GTA 
[1] http://www.swynk.com/friends/green 
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Topológiák és alapszolgáltatások 

E havi cikkem első részében megismertetem a Kedves Olvasót 
néhány gyakran használt tűzfaltopológiával, a második rész- 
ben pedig már valós tesztrendszert építünk fel, melyben az 
ISA legalapvetőbb szolgáltatásait (böngészés, webkiszolgáló 
publikálás, FTP szolgáltatás, levelezés) fogjuk megvalósítani. 
Szeretnék azonban előrebocsátani néhány dolgot: a topoló- 
giarészben leírtak nem kötelezőek, mindössze néhány ötletet 
adnak egy tűzfalrendszer kiépítéséhez. A kiszolgálók publiká- 
lását pedig senki ne tegye éles környezetben az itt leírtak 
szerint! Ez úgy érzem magyarázatra szorul: a valós életben, 
mielőtt , bedugjuk a kábeleket", tegyünk meg mindent, hogy 
a lehető legbiztonságosabb rendszert állítsuk üzembe! Ez 
most azért marad el, mert az éles rendszerek üzembeállítása 
általában a hibakereséssel kezdődik, erre pedig ráérünk akkor 
is, amikor éles rendszert építünk, vagy már mindent tudunk, 
ami egy hiba elhárításához szükséges lehet. 


Tűzfaltopológiák 

Bemelegítésként kezdjük a legegyszerűbb topológiával. Itt 
a tűzfal kétlábú (vagyis két hálózati kártya van benne), és 
nem alkalmazunk DMZ-t (erről majd később). 









Internet 


a Egyszerű (router-hez hasonló) topológia 


Ez a topológia leginkább kisvállalati környezetben alkal- 
mazható, főleg olyankor, amikor nincs állandó Internet- 
kapcsolat, és így nincsenek a külvilágnak nyújtott szolgál- 
tatások (például a webkiszolgáló az Internet-szolgáltatónál 
van). Persze ez alól is lehetnek kivételek. Nagyon sokszor 
kényelmi, vagy éppen teljesítményokok miatt ezt a topoló- 
giát alkalmazzák, és nem alakítanak ki DMZ-t. Ez esetben a 
kiszolgálók a LAN-on helyezkednek el. 

A következő topológia egy kicsit bonyolultabb, itt már há- 
romlábú a tűzfal, és van DMZ is. Már sokszor említettem, 
lássuk hát mi is a DMZ: a DMZ a demilitarizált zóna rövidí- 
tése. Mint az nevéből is sejthető, ez egy elkülönített zóna, 
ami arra szolgál, hogy itt helyezzük el azokat a kiszolgáló- 
kat, melyek olyan szolgáltatásokat nyújtanak, melyeket 
bárki elérhet az Internet felől. Ennek legtipikusabb példája 
nyilvánvalóan a webszolgáltatás. 
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a Háromlábú tűzfal DMZ-vel 


Talán az ábrán nem igazán látszik, és még igencsak egysze- 

rűnek tűnik a dolog, de azért egy ilyen rendszer beállítása- 

kor már lehetnek nehézségek. Vegyünk egy egyszerű példát: 

a DMZ-ben egyetlen webkiszolgáló van, amelyen egy part- 

nereinknek szánt weblapot helyezünk el. Ezen mindig az 

éppen aktuális árlistánkat tekinthetik meg, ami a LAN-on 

elhelyezett SOL Server-ből származik. 

Lássunk erre két megoldást: 

1. A webkiszolgálón levő árlisták minden lekérdezéskor auto- 
matikusan frissülnek. 

Mivel ez esetben webkiszolgálónk közvetlenül az SOL Ser- 

ver-től szerez adatokat, fontos kritérium, hogy senki ne ér- 

hesse el közvetlenül ezt a kiszolgálót, vagyis a tűzfalon 

egy reverse proxy-nak kell működnie. Lássuk milyen szabá- 

lyokat kell létrehoznunk: 

"? Először is állítsuk be a webkiszolgáló eléréséhez szüksé- 
ges reverse proxy-t. 

"0 Biztosítsuk, hogy a webkiszolgáló lekérdezhessen az 
adatbázisból. 

- És végül engedélyezzük, hogy a belső hálózatról a fel- 
használók arra jogosult csoportja frissíthesse a weblapokat. 

Ez így igen egyszerűnek tűnik, de a későbbiekben látni 

fogjuk, hogy a valóságban egy-egy ilyen szabály létrehozá- 

sa több lépésből áll. 

2. A webkiszolgálón levő árlisták frissítését a belső háló- 
zatról kezdeményezik (kézi, vagy automatikus frissítés) 

Az előző esethez képest nagyon fontos különbség az, hogy 

itt a DMZ-ből nem kezdeményezünk kapcsolatot a belső há- 

lózat felé. Nyilvánvalóan ez esetben sem örömteli, ha vala- 

ki betör a webkiszolgálóra, de sokkal kisebb veszélyt jelent. 

Éppen ezért, hacsak teljesítményproblémák miatt másra 

nem kényszerülünk, használjunk itt is reverse proxy-t: 

"B Állítsuk be a webkiszolgáló eléréséhez szükséges rever- 
se proxy-t, vagy az ezt helyettesítő engedélyező szabályt. 
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2 Engedélyezzük a webkiszolgálón levő tartalom frissíté- 
séhez szükséges forgalmakat 
A két megoldás között van némi különbség. Jó, jó, ezt a vak is 
látja, de az első megoldás használhatóság szempontjából sok- 
kal igényesebb, főleg akkor, ha az árlisták gyakran változnak. 
A következő topológia a paranoiásoknak való (bár kétség- 
telenül vannak előnyei). Ez az előzőhöz teljesen hasonló, 
mindössze annyi a különbség, hogy itt minden egyes szol- 
gáltatáshoz külön DMZ tartozik. (A szemléltetés kedvéért 
csak plusz két DMZ-t rajzoltam, nehogy szegény tűzfal úgy 
nézzen ki, mint egy sündisznó :) ) 
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a Többlábú tűzfal több DMZ-vel 


Ennek a megoldásnak nyilvánvaló hátránya, hogy bonyo- 
lultabb a tűzfalat beállítani (gondoljunk csak például az út- 
vonalválasztásra) , viszont határozott előnye az, hogy ha az 
egyik DMZ-ben levő kiszolgálóra valakinek sikerülne betör- 
nie, attól még nem fér hozzá ennek a kiszolgálónak a fel- 
használásával a többi DMZ kiszolgálóihoz. 

Most induljunk ki ismét a legegyszerűbb topológiánkból 
(persze az alább ismertetett megoldások használata nem 
zárja ki a DMZ használatát, csak szeretném, ha az ábra átte- 
kinthető maradna). Létrehozhatunk olyan zónákat is, me- 
lyek olyan szolgáltatásokat biztosítanak, melyeket jó eset- 
ben senki nem vesz észre. Ilyen lehet például a vírusszűrés 
(ezt azt hiszem nem kell részletezni) , vagy a tartalomszűrés 
(mielőtt olyan szoftvert szeretnénk üzembe helyezni, amely 
nem engedélyezi az olyan webhelyek megtekintését, ame- 
lyen egy bizonyos s-el kezdődő, és x-re végződő szó gyakran 
előfordul, előbb nézzük meg a naplófájlokat, nehogy a fő- 
nökség nemtetszésével találjuk szembe magunkat :) ). De 
létrehozhatunk olyan zónát is amelyből a tűzfalunk/tűzfa- 
laink felügyeletét látjuk el. 

tetett ) 
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5 Tűzfal kapcsolódó szolgáltatásokkal 
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Az utolsó topológia leginkább az előző részben ismertetett 


gyorsítótár-lánc kialakításához hasonlít. Ha a vállalatunknak 
több fiókirodája, vagy részlege van, melyek egymástól telje- 
sen függetlenül működnek, lehet hogy ezeket külön tűzfal 
mögé akarjuk helyezni. Ha már kialakítottunk gyorsítótár- 
láncot félig nyert ügyünk van, hiszen a szükséges eszközök 
megvannak, csak a megfelelő beállítások szükségesek. Eb- 
ben a topológiában a központi tűzfal mögötti terület lehet a 
DMZ, és ide kapcsolódhatnak a fiókirodák tűzfalai is (Ez csak 
egy lehetséges megoldás. Kialakíthatjuk a rendszert úgy is, 
hogy létrehozunk DMZ-t/DMZ-ket a külső szolgáltatások szá- 
mára, és a központi tűzfal mögötti zónában helyezzük el a 
fiókirodák által közösen használt kiszolgálókat) . 
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o Két (vagy több) tűzfal között elhelyezkedő DMZ 


Most, hogy általánosságban bemutattam a legfontosabb 
topológiákat, térjünk rá a tesztrendszerünkre, melyet a ké- 
sőbbi kísérletezések során használni fogunk. Természete- 
sen nem kötelező ragaszkodni az alábbiakban leírtakhoz, 
sőt! Ha valaki kísérletezgetni akar, tegye bátran, abból le- 
het a legtöbbet tanulni! 


Az ISA tesztrendszer felépítése 

ISA tesztrendszerünk központjában egy háromlábú ISA Ser- 

ver fog elhelyezkedni, melynek IP címeit a következők sze- 

rint osztottam ki: 

"2 Internet zóna: 192.168.1.1, Subnet mask: 
255.255.255.248 

"I DMZ: 192.168.2.1, Subnet mask: 255.255.255.248 

"0 Intranet zóna: 192.168.3.1, Subnet mask: 
255.255.255.248 

A szabályok kialakítása során az egyes funkciókat össze 

fogjuk vonni, hogy kevesebb gépre legyen szükség. Ezek 

szerint az Intranet zónánk egyetlen gépből fog állni: 

Ezen a gépen az e cikkben leírtak megvalósításához futnia kell 

egy web, egy FTP és egy SMTP kiszolgálónak, az IP címe nálam 

192.168.3.4 lett, alapértelemzett átjárója pedig legyen az ISA. 

Az Internetet szintén egy gép fogja megszemélyesíteni, 

aminek az Intranet géphez teljesen hasonlónak kell lennie, 

de IP címe nyilvánvalóan más, legyen mondjuk 192.168.1.6, 

ennél a gépnél is legyen az alapértelmezett átjáró az ISA. 

A DMZ-ben levő gép (ezt most még nem fogjuk használni), 

csak a változatosság kedvéért legyen ugyanolyan, mint a má- 

sik kettő, IP címe legyen 192.168.2.6, az alapértelmezett átjá- 

rója pedig ismét csak a változatosság kedvéért, legyen az ISA. 
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a Az ISA tesztrendszer felépítése 


Most már szinte minden készen áll ahhoz, hogy elkezd- 
jünk szabályokat létrehozni, és tesztelni azokat. Valami 
azonban még hiányzik! Ez a valami a DNS, de ezt most 
egy elegánsnak éppen nem nevezhető huszárvágással ki- 
hagyjuk a rendszerünkből (legalábbis egyelőre) . 


Hogy fogunk tesztelni? 

Mindig a lehető legegyszerűbb módon. Vagyis a megkülön- 
böztethetőség érdekében a webkiszolgálókon az alapértel- 
mezett nyitólap lehetőleg utaljon arra, hogy mit is látunk. A 
HTTP szolgáltatások kipróbálását webböngészővel, az FTP és 
SMTP szolgáltatásokét pedig parancssorból célszerű végezni. 


Az ISA alapszolgáltatásainak beállítása 

Az ISA beállításait a Windows 2000 környezetben már meg- 

szokott Microsoft Management Console segítségével végez- 

hetjük el. Két fő fát találhatunk a jobb oldali mezőben, az 

egyik a , Servers and Arrays" a másik a , H.323 Gatekeepers" 

nevet viseli. Ez utóbbit most hagyjuk figyelmen kívül. 

A ,Servers and Arrays"-ben egy darab kiszolgálót láthatunk, 

amit én a hangzatos ISA névvel láttam el, gyakorlatilag ez alatt 

tudunk beállítani mindent. A főbb beállítandók a következők: 

0 Monitoring: itt tekinthetjük meg a felhasználók nyitott 
kapcsolatait, a riasztásokat, valamint a jelentéseket 

"7 Publishing: itt tehetjük közzé kiszolgálóinkat az Interneten 

I Bandwith Rules: a rendelkezésre álló sávszélesség felügye- 
letét biztosító szabályok 

0 Policy Elements: ezek képezik az ISA által kikényszerített 

házirendek alapját 

Cache Configuration: a gyorsítótár jellemzőinek beállítá- 

sa, letöltések időzítése 

0 Monitoring Configuration: Jelentéskészítés és a riasztá- 
sok beállításai 

0 Extensions: ez biztosítja az ISA bővíthetőségét, itt ad- 
hatunk hozzá külső gyártó, a Microsoft, vagy akár sa- 
ját magunk által készített szűrőket 

0 Network Configuration: az útvonalválasztás és a belső 
hálózat jellemzőinek beállítása 

0 Client Configuration: a tűzfalügyfelekre érvényes beál- 
lítások 
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Webkiszolgáló közzététele 
Most, hogy már alapvetően ismerjük, hogy mit hol tehe- 
tünk meg, publikáljunk is egy webkiszolgálót: 
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5 Webkiszolgáló publikálása 


"I Navigáljunk a PublishingYWeb Publishing Rules-hoz. 

"8 Kattintsunk a Create Web Publishing Rule-ra a jobb ol- 
dalon, a megjelenő ablakban nevezzük el a szabályt, 
és menjünk tovább. 

"? A következő képernyőn kiválaszthatjuk, hogy mely cé- 
lokra (Destination Set) érvényesítsük ezt a szabályt, 
mivel még nem hoztunk létre ilyet, mondjuk azt, hogy 
Any destinations". 

"0 Ezután azt állíthatjuk be, hogy kitől is fogadunk kéré- 
seket. Három lehetőségünk van: bárkitől, adott IP 
címről, vagy adott felhasználóktól és felhasználói cso- 
portoktól. Válasszuk most az , Any reguest"-et. 

"B Ezután állíthatjuk be a szabály által végrehajtott cse- 
lekvést. Vagy elutasítjuk a kérést, vagy továbbítjuk 
egy belső kiszolgálónak, amelynek itt tudjuk beállíta- 
ni az IP címét, és hogy milyen típusú (HTTP, SSL, FTP) 
kéréseket milyen portokra továbbítunk. 

Majdnem készen is vagyunk, de ha a külső ügyféllel most 

próbálnánk elérni a belső kiszolgálót, akkor nem kapunk 

választ. Ahhoz, hogy tényleg látható legyen a publikált 
kiszolgálónk, be kell állítanunk az ISA külső lábán egy 

Listener-t (fülelő? :) ). 

"0 Kattintsunk jobb gombbal az ISA kiszolgálóra, és válasz- 
szuk a Properties-t. 

"2 Menjünk az Incoming Web Reguests fülre, és válasszuk 
ki a , Configure listeners individually per IP address7- 
t, és kattintsunk az Add gombra. 

"0 A legördülő menükből válasszuk ki az ISA-t és külső IP 
címét, OK, aztán érvényesítsük ezt a beállítást (Apply). 

"8 A megjelenő ablakban mondjuk azt, hogy mentjük a 
változásokat, és újraindítjuk a szolgáltatást. 
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0 Web Listener beállítása 


Próbáljuk ki bátran, a külső ügyfél most már el tudja érni a 
webkiszolgálót. Ha már így belejöttünk, publikáljuk gyor- 
san FTP és SMTP kiszolgálónkat is. 


FTP és SMTP kiszolgáló közzététele 

Nem véletlenül vontam össze ezt a két lépést. Az FTP és az 

SMTP kiszolgáló közzététele gyakorlatilag ugyanúgy zajlik, 

mindössze a protokoll megadásakor van eltérés. 

"0 Válasszuk a Publishing-ből most a , Server Publishing 
Rules"7-t. 

"0 Nevezzük el a létrehozni kívánt szabályt. 

0 A következő ablakban adjuk meg a belső kiszolgáló IP cí- 

mét, és az ISA külső IP címét, amelyre az adott protokoll 

szerinti kéréseket várni fogja (a mi ISA Server-ünknek csak 

egy külső IP címe van, tehát most állítsuk be ezt). 

Állítsuk be, hogy milyen protokollra legyen érvényes ez 

a szabály, esetünkben ez értelemszerűen FTP Server, 

vagy SMTP Server lesz. 

0 A következő ablakban beállíthatjuk, hogy minden kérést el- 
fogadunk-e, vagy csak bizonyos IP címről érkezőket, már csak 
egy OK-t kell nyomnunk - tulajdonképpen végeztünk is. 


Szolgáltatások engedélyezése a belső felhasználóknak 
Az Internet felől most már minden szolgáltatásunk elérhető, 
de ez saját felhasználóinkat még nem teszi túl boldoggá, 
mert ők még semmit nem tudnak elérni az Interneten. Hogy 
ezen az állapoton változtassunk, a következőket kell tennünk: 
"0 Válasszuk az Access Policy menüből a Protocol Rules-t. 
"I A jobb oldalon válasszuk ki a Create a Protocol Rule for 
Internet Access-t. 
"0 Nevezzük el a szabályt, és haladjunk tovább. A követke- 
ző ablakban válasszuk ki azokat a protokollokat, me- 
lyeket engedélyezni akarunk a belső felhasználóknak 
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(ha a Show only selected protocols négyzetből kivesszük 
a pipát, megcsodálhatjuk, hogy milyen sok protokollt is- 
mer az ISA Server). 

Állítsuk be, hogy milyen időpontokban legyen érvényes 
ez a szabály. Mivel még nem hoztunk létre ilyen időponto- 
kat a Policy Elements között, mondjuk azt, hogy , Always". 
"I A következő ablakban beállíthatjuk, hogy kiktől is jöhet- 
nek ezek a kérések (bárki, adott IP címek, adott fel- 
használó, vagy csoport). 

Ismét majdnem készen vagyunk, de még át kell vereked- 
ni magunkat az ISA beépített tartalomszűrésén. Válasszuk 
most az Access Policy-ből a Site and Content Rules-t, 
majd a jobb oldalon a ,Create a Site and Content Rule"-t. 
Nevezzük el a szabályt, lépjünk tovább, majd a szabály 
által végrehajtandó cselekvéseknél válasszuk az , Allow"-t. 
B Állítsuk be, hogy mely kiszolgálókat kereshetik fel felhasz- 
nálóink. Még mindig nem hoztunk létre Destiantion 
Set-et, tehát válasszuk az , All destinations"7-t. 

A továbbiakban alkalmazzuk ugyanazokat a beállításokat, 
mint az előbb létrehozott Protocol Rule-nál, és hopp, 
már készen is vagyunk, ki lehet próbálni a szabályok 
működését. 





CEHZZEELAEZ 


Protocols 


Select the protocols to which this nie applies. 





[7 Show only selected protocols, 





Cane 


5 A belső felhasználóknak engedélyezett protokollok 





Hát ennyi lett volna erre a hónapra. Legközelebb az ISA 
házirendjének beállításait fogjuk alaposabban áttekinteni 
(ezzel együtt persze szűréseket fogunk végezni tartalom és 
időpontok szerint), és hogy kényelmesebben tudjuk hasz- 
nálni tesztrendszerünket, csinálunk hozzá DNS-t is. Emel- 
lett, hogy ne legyen fölösleges az ISA-ban levő harmadik 
hálózati kártya, áttérünk a DMZ használatára, amit ezután 
már következetesen alkalmazni fogunk. 


BP, MCSE 
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- Komponensek 


(VI. rész) 


Ezúttal az ASP programozás során hasznos, az Internet In- 
formation Server-be (vagy az operációs rendszerbe) eleve 
beépített, programozható komponensekről ejtünk néhány 
szót. A szöveges fájlok elérésére használt komponenst már 
eddig is használgattuk, de most bemutatjuk a teljes arze- 
nált - némelyikükről sokan azt sem tudják, hogy létezik. 
Az adatbázis-kezeléshez használható ASP objektumokat - 
leszámítva a bináris fájleléréshez használt Stream objektu- 
mot - egy későbbi részben, külön tárgyaljuk majd. Az első 
néhány bemutatott komponens nem függ szorosan az ASP- 
től, ezért ezek ismerete nemcsak a web-, de a script- és Vi- 
sual Basic programozók számára is hasznos lehet. A példa- 
programok - mint mindig - az [1] címről tölthetők le. 


A fájlrendszer elérése 

Cikksorozatunk példáiban akarva-akaratlanul is feltűnt már 

a FilegystemObject [2] komponens. Az FSO-t a helyi és há- 

lózati meghajtók elérésére, mappák és fájlok kezelésére 

(másolás, átnevezés, stb.), valamit szöveges tartalmú állo- 

mányok olvasására és írására használhatjuk. Az FSO objek- 

tumcsalád a következő tagokból áll: 

0 FilegystemObject - az objektumcsalád , őse", számos 
saját funkcióval 

0 Drive - egy (helyi vagy hálózati) logikai meghajtót jel- 
képező objektum 

0 Drives - a számítógépen elérhető Drive objektumokat- 

tartalmazó kollekció 

Folder, Folders - egy mappát jelképező objektum, vala- 

mint Folder objektumokat tartalmazó kollekció 

0 File, Files - fájlokat jelképező objektum és File objek- 
tumokat tartalmazó kollekció 

"b TextStream - szöveges fáljok olvasására, írására hasz- 
nált adatfolyam-objektum 


Vf 


A FilegystemObject objektum 

Mindenekelőtt hozzuk létre az objektumot. A FileSystem- 
Object komponenst a felhasználás helyén közvetlenül, vagy 
az cOBJECT: elem segítségével - akár a global.asa-ban - is 
létrehozhatjuk: 


Set oFSO - Server.CreateObject 


5, ("Scripting.FileSystemObject") 


LOBJECT RUNAT-Server SCOPE-Application ID-oFSO 
PROGID-"Scripting.FileSystemObject"5 
£/OBJECT2 


Ha az cOBJECT:5 formátumú definíciót nem a global.asa- 
ban, hanem az adott oldal tetejére szúrjuk be, ne felejtsük 
el a SCOPE értékét , Page"-re állítani! 

Ha az oldal tetejére vagy a global.asa-ba beszúrjuk az 
alábbi sort: 
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£ 


£1--METADATA TYPE-"TypeLib" FILE-"scrrun.dll"--5 


.. akkor nem kell a típuskönyvtár elemeinek értékeit keres- 
gélnünk, hanem közvetlenül használhatjuk az értékek neveit. 
A FileSystemObject objektum Drives jellemzője a Drives 
kollekciót adja vissza, benne az elérhető logikai meghajtó- 
kat jelképező Drive objektumokkal. Ebből kiindulva a teljes 
fájlrendszer bármely pontjára elérhetünk, de a GetFolder() 
és a GetFile() metódus segítségével közvetlenül is hozzá- 
férhetünk egy-egy adott Folder, illetve File objektumhoz: 


Set oFile - oFSO.GetFile("filenev.txt") 
Set oFolder - oFSO.GetFolder("C:Wmappal") 


Ha az aktuális mappát szeretnénk, írjuk ezt: 
Set oFolder - oFSO.GetFolder(".") 
Egy adott meghajtót pedig így érhetünk el: 
Set oDrive - oFSO.GetDrive("C:NW") 


A GetDrive() imát Ben átadhatjuk. aga a betűjelet 
fejlserertehate"]. A GetSpecialFolder() metódus a Win- 
dowsban gyakran használt fontosabb mappák közvetlen 
elérésére használható (specfld.asp). Paraméterként az 
alábbi értékeket adhatjuk át: 


NA [ág IT ÉG 
WindowsFolder 0 A Windows fájlok helye 
(pl. C: IWINNT) 








SystemFolder ÜL A Windows rendszerfájlok 
helye (pl. C: IWINNTISystem32) 
TempFolder ú Az átmeneti fájlok helye 


(pl. C: IWINNTITemp) 


Ha a global.asa-ban vagy az .asp oldal tetején megadtuk a 
típuskönyvtárat (a c!- METADATA --s elem segítségével), 
akkor használhatjuk az értékek neveit, különben csak az 
értékeket önmagukat adhatjuk át a függvénynek. Például: 


oFSO.GetSpecialFolder(WindowsFolder) " 5 0 
oFSO.GetSpecialFolder(0) " - WindowsFolder 


A CopyFile(), CopyFolder(), DeleteFile(), DeleteFolder(), 
MoveFile(), MoveFolder() metódusok segítségével két (az 
FSO objektum létrehozása után egy) sorban másolhatunk, 
mozgathatunk, törölhetünk mappát vagy fájlokat, például: 


OFSO.CopyFile("c:lboot.ini", "e:lboot.bak") 
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A DriveExists() , FolderExists(), FileExists() metódusok egy- 
egy meghajtó, mappa illetve fájl meglétének vizsgálatára 
használhatók: értékük True, ha az adott objektum létezik. 

A GetTempName() metódus egy véletlenszerűen generált 
fájlnevet ad vissza, amit átmeneti fájlok létrehozására 
használhatunk - ezt értelemszerűen illik az átmeneti fájlok 
könyvtárában tennünk: 


sTempName - oFSO.GetTempName ( ) 
Set oTempFld - oFSO.GetSpecialFolder(TempFolder) 
Set oTempFile - oTempFld.CreateTextFile(sTempName) 


CreateTextFile() metódussal a FileSystemObject önmaga, va- 
lamint minden Folder objektum rendelkezik. Ha a metódust 
az FSO-ból hívjuk, meg kell adnunk a létrehozandó fájl teljes 
útvonalát; míg ha egy Folder objektumból (mint fent) , akkor 
elég a fájlnevet megadni, és az az adott mappában jön majd 
létre. A CreateTextFile() a fájlnév mellett két opcionális pa- 
ramétert vár, a második paraméter arra vonatkozik, mi tör- 
ténjen, ha az adott fájl már létezik. True érték esetén fe- 
lülírjuk, az alapértelmezés False: ilyenkor hiba keletkezik. A 
harmadik paraméter a szövegformátum: True esetén a fájl 
Unicode, ha pedig nem adjuk meg, vagy értéke False, akkor 
a fájl tiszta ASCII kódolással kerül a lemezre. 

Az OpenTextFile() annyiban különbözik az előzőtől, hogy 
ezzel a metódussal csak az FSO rendelkezik. Itt a fájlnév 
mellett még három paraméter található: az iomode értéke 
lehet ForReading (1, olvasásra, a fájl nem írható), ForWri- 
ting (2, írásra, a fájl nem olvasható), ForAppending (8, a 
meglévő fájl végére írunk). A harmadik paraméter egy boo- 
lean érték, True esetén a fájlt létrehozzuk, ha még nem lé- 
tezik, False esetén nem (ez az alapértelmezés is). Végül, a 
negyedik paraméter ismét a formátumot határozza meg, 
TristateTrue (-1) esetén a fáljt Unicode, TristateFalse (0) 
esetén ASCII kódolással, TristateUseDefault (-2) esetén 
pedig a rendszer alapértelmezett beállításával nyitjuk meg. 
Mindkét metódus esetében csak a fájl neve a kötelező pa- 
raméter, az összes többi elhagyható. 


Mind a CreateTextFile(), mind az OpenTextFile() által visz- 
szaadott objektum TextStream típusú, ami a fájlba írás- 
ra, illetve abból olvasásra használható (később bemutat- 
juk). Ne keverjük ezt össze a fájlokat jelképező File ob- 
jektummal, ami a fájl paramétereinek lekérdezésére, 
módosítására, a fájlok másolására, törlésére használható. 


Néhány fájlnév-feldolgozáshoz használható függvény ma- 
radt a végére. Mindegyikük tulajdonsága, hogy paraméter- 
ként egy fájlnevet várnak (a fájlnak viszont nem kell létez- 
nie!). A namepart.asp a következő eredményt generálja: 


c: WmappalWmappa2 proba. txt 

GetFileName() - proba.txt 

GetBaseName() - proba 

GetExtensionName() -— txt 

GetAbsolutePathName() - C:ImappallmappaZiproba.txt 
GetParentFolderName() - C:VWmappallWmappa2 


GetDriveName() - C: 
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A Drives, Folders, Files kollekciók 

E kollekciók mindegyike az általa tartalmazott objektumok- 
ról lett elnevezve. Ha a Drives koilekciót lekérjük az FSO- 
tól, máris kipróbálhatjuk a feldolgozását (drives.asp). 
Legegyszerűbben egy For...Each ciklusba tölthetjük be, 
aminek törzsében egyenként megkapjuk a Drive objektu- 
mokat; de a kollekció méretét (.Count) és egy-egy adott 
elemét is lekérhetjük (.Item) - a kollekciókra vonatkozó 
általános szabályok figyelembevételével. 


A Drive objektum 

Nézzük, mit találunk a drives.asp példaprogram For...Each 

ciklusának belsejében! Ott megtalálható az összes Drive 

jellemző, most csak néhány fontosabbat mutatunk be. 

Mindenekelőtt itt van az .IsReady jellemző. Ha egy Drive 

objektum .IsReady jellemzője False értéket ad vissza, le- 

gyünk óvatosak, mert ilyenkor a legtöbb jellemző olvasási 

kísérlete hibát ad vissza. Ha viszont az eszköz rendelkezés- 

re áll, sok mindent lekérdezhetünk, például: 

"0 .DriveType - a meghajtó típusazonosítója 

0 .Filegystem - a használt fájlrendszer 

0 .TotalSize, .AvailableSpace, .FreeSpace - a meghajtó 
teljes, felhasználható és szabad részének mérete 

A .RootFolder metódus a meghajtó gyökérkönyvtárának 

Folder objektumát adja vissza - és máris megérkeztünk a 

következő fejezethez. 


A Folder objektum 

A Folder objektum - nevéhez híven - egy mappát jelképez. 
A folder.asp példaprogram bemutatja az objektum haszná- 
latát. Az .Attributes paraméter bitmezőként tartalmazza a 
mappa paramétereit (ugyanez igaz lesz a File objektumra 
is), az egyes bitek értéke és jelentése az alábbi: 




















TE Érték Megjegyzés 

ReadOnly 1 írásvédett 

Hidden e rejtett 

System 4 rendszer 

Directory 16 mappa (csak olvasható paraméter) 
Archive 32 archív 

Alias 1024 parancsikon (shortcut) 


(csak olvasható paraméter) 
Compressed 2048 tömörített (NTFS-en) 
(csak olvasható paraméter) 





a Fájl- és mappaattribútumok 

Az egyes jellemzőket természetesen bitműveletek segítsé- 
gével lehet kiolvasni és módosítani. Az ,Archive" mező 
kiolvasása például így történhet: 

If oFolder.Attributes And 32 Then ... 

Ha be szeretnénk állítani az adott értéket, akkor: 
oFolder.Attributes - oFolder.Attributes Or 32 


... ha pedig törölni: 


oFolder.Attributes - oFolder.Attributes And Not 32 
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Ne feledjük el, hogy csak az írható attribútum-mezők ér- 
tékeit módosíthatjuk (bár a csak olvasható mezők írása hi- 
bát nem okoz). A Folder objektum metódusai segítségével 
másolhatjuk, törölhetjük, mozgathatjuk a mappát; a Crea- 
teTextFile() metódus pedig - már szó volt róla - szöveg- 
fájlok létrehozására való. 

A Folder objektum két másik kollekciót adhat vissza: a 
.SubFolders jellemző az almappákat (Folders kollekciót), 
míg a .Files jellemző a mappában található fájlok gyűjte- 
ményét (Files kollekciót) adja vissza. 


A File objektum 

A File objektum egy fájlt jelképez a fájlrendszerben. A 
szokásos metódusok (.Copy(), .Move(), .Delete()) mellett 
egy .OpenAsTextStream() metódust is tartalmaz. A metó- 
dus által visszaadott TextStream objektum segítségével ír- 
hatjuk vagy olvashatjuk a fájl tartalmát. A File objektum 
is jónéhány beépített jellemzővel bír, a legegyszerűbb, ha 
ezeket a file.asp kipróbálása során ismerjük meg - és ne 
feledjük, a teljes FilegystemObject referencia a [2] címen 
mindig rendelkezésre áll. 


A TextStream objektum 

A CreateTextFile(), OpenTextFile() és az OpenAsTextStream() 

metódusok egy-egy TextStream objektumot adnak vissza, 

amely az adott - éppen létrehozott vagy megnyitott - szöve- 

ges állomány írására, olvasására használható (textstream.asp). 

Fontos, hogy az adatfolyamban csak előre haladhatunk, 

visszafelé haladásra nincs mód (ha erre lenne szükség, újra 

meg kell nyitni a fájlt) . Az objektum jellemzői a következők: 

"0 .Line, .Column - csak olvasható jellemzők, az aktuális 
sor, és oszloppozíciót adják vissza 

"0 .AtEndOfLine - értéke True, ha a mutató egy sor végén áll 

0 .AtEndOfStream - értéke True, ha a mutató a fájl végén áll 

A metódusok pedig az alábbiak: 

"b .Read(x) - x karaktert olvas a fájlból 

0 .ReadLine - egy sort beolvas a fájlból (a sorvégjelet nem 
adja vissza!) 

"0 .ReadAll - a fájl teljes tartalmát beolvassa 

0 .Skip(x) - a fájl olvasásakor x karaktert lép előre (kihagy) 

"0 .SkipLine - a fájl olvasásakor kihagyja a következő sort 

"0 .Write() - a paraméterként átadott szöveget a fájlba írja 

0 .WriteLine() - a paraméterként átadott szöveget a fájlba 

írja, majd a végére egy sorvégjelet tűz 

.WriteBlankLines(x) - x üres sort ír a fájlba 

0 .Close() - a fájl lezárása, a munkát illik ezzel befejezni 


JA 


Az ADO.Stream objektum 

Bár a bevezetőben azt állítottam, hogy az ADO objektumcsa- 
ládról most nem lesz szó, egy objektum erejéig most kivételt 
teszek: ez pedig a Stream. A TextStream objektum ugyanis 
szöveges fájlok írására/olvasására úgy-ahogy alkalmas, de 
mit tehetünk, ha nekünk bináris állományokat kell kezel- 
nünk? Vagy mit tehetünk ha szöveges fáljban bár, de - uram 
bocsá" - pozícionálni szeretnénk? Használjuk az ADO.Stream 
objektumot! A teljes objektumreferencia a [3] címen érhető 
el, de a fájlok kezeléséhez szükséges fontosabb jellemzőket 
és metódusokat mi is bemutatjuk (stream.asp). 

Az ADO.Stream objektumot az alábbi hívással hozhatjuk létre: 
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Set oStream - Server.CreateObject("ADODB.Stream") 


Ezután következhet az igazi munka: 

"8 Mindenekelőtt a Stream-et meg kell nyitnunk az .Open 
metódus segítségével. 

"5 A Type paraméter határozza meg, hogy szöveges, vagy 
bináris állományt kezelünk. Értéke 1, ha bináris, 2, ha 
szöveg - ez utóbbi az alapértelmezés is 

"A .LoadFromFile(), illetve .SaveToFile() metódusok a Stream 
fájlból való betöltésére illetve oda mentésére használhatók 

2 Szöveges fájlok használatakor .charset jellemző beállítása 
nagyon fontos! A Stream-ből való olvasáskor, illetve 
abba íráskor a szöveg az itt megadott karaktertáblát 
használja. Az alapértelmezés ugyanis Unicode, még 
akkor is, ha az eredeti fájl nem Unicode típusú 


Az érvényes karaktertábla-neveket a Registry-ben, a 
HKEY CLASSES ROOTWIMEDatabaselCharset 

kulcs alatt találjuk. 

Magyar szöveghez használjuk az , iso-8859-2"7-t. 


"0 A .Position jellemző mutatja, hogy éppen hol tartunk 
a streamben (nincs Line illetve Column érték) - ez vi- 
szont írható, így szabadon pozicionálhatunk - de vi- 
gyázzunk, bájtonként, nem karakterenként (Unicode)! 
A Stream a 0-s pozíciónál kezdődik. 

"b A Size a Streamben található bájtok számát adja vissza. 
(Unicode szöveges adat esetén ez a karakterek számá- 
nak duplája!) 

"0 A .Read(x) illetve .ReadText(x) metódusok x bájt (ha 
nem adjuk meg, teljes stream) beolvasására használha- 
tók. Bináris stream esetén a Read, szöveges esetén a 
ReadText használandó. 

0 A .Write() illetve .WriteText() segítségével írhatunk a 
Stream-be. A .WriteText második paramétere határoz- 
za meg, hogy sorvégjel kerüljön-e a kiírt szöveg végé- 
re. Ha nem adjuk meg, vagy értéke 0, akkor nem; ha 
azonban megadjuk (1), akkor a szöveg után egy újsor 
karakter is kerül a szövegbe. 

"8 Az .EOS jellemző True értéke jelzi, ha a Stream végére 
értünk; a SetEos() metódus pedig a Stream végét az 
aktuális pozícióra állítja (a Stream többi része elveszik). 

"8 A munka végén itt se felejtsük el meghívni a Stream 
lezárására való .Close() metódust. 


A Dictionary objektum 

A Dictionary objektum egy különleges tárolóobjektum 
(akinek ez mond valamit: asszociatív tömb). Lényege, 
hogy benne bármilyen adatot tárolhatunk, és az egyes 
adatokhoz szöveges címzés segítségével (kulccsal) jutha- 
tunk hozzá. Például (dictionary.asp): 


Set opic -— 

b Server.CreateObject("Scripting.Dictionary") 
oDic.Add "kulcsil", "ertek 1" s 
oDic.Add "kulcs2", 123 


oDic.Add "kulcs3", oDpic 


A fenti példa első sorában létrehoztunk egy Dictionary objek- 
tumot (, Scripting. Dictionary") majd különféle elemeket ad- 


A MICROSOFT MAGYARORSZÁG SZAKMAI MAGAZINJA 
2001. 07. 


feb 


26 


2 


BUSINESS INTERNET 


tunk hozzá, mindegyiket gondosan felcímkézve. Látható, hogy 
az érték lehet szöveg, számszerű érték, sőt objektum is; mi 
perverz módon saját magát adtuk hozzá a tömbhöz, aminek 
sok értelme ugyan nincs, de demonstrációs célra nagyszerű :-). 
Az egyes értékeket két különböző módon (bár a két mód tu- 
lajdonképpen ugyanaz) is kihalászhatjuk a Dictionary-ből: 


Response.Write oDic("kulcs1l") 


Response.Write oDic.Item("kulcs2") 


Azaz, használhatjuk az objektum .Item jellemzőjét, ami 
egy adott kulcsú értéket ad vissza, vagy írhatjuk a kulcsot 
közvetlenül az objektum neve után is. És hogy a rekurzió 
működik, mi sem jobb bizonyíték, minthogy az alábbi kife- 
jezés eredménye 123: 


Response.Write oDic("kulcs3")("kulcs2") 


Néhány további jellemző illetve metódus: 

0 A .Count jellemző a Dictionary-ban található elemek szá- 
mát adja vissza. 

0 A .Key jellemző egy kulcs nevének megváltoztatására 
használható: 


oDic.Key("regikulcs") - "ujkulcs" 


"0 Az. .Exists() metódus értéke igaz, ha a paraméterként á- 
tadott kulcs már létezik. 

"0 A .Remove() metódus egy adott kulcsú, a .RemoveAll() 
metódus az összes érték törlésére való. 

"0 A .Keys() metódus a kulcsokat tartalmazó kollekciót, az 
.Items() metódus pedig az elemeket tartalmazó kollek- 
ciót adja vissza. 


A beépített IIS komponensek 

Mostantól kifejezetten az ASP programozás céljára fejlesz- 
tett objektumokról lesz szó. Az IIS ugyanis több beépített, 
egyszerű és bonyolultabb komponenst tartalmaz, amelyek 
a hétköznapi feladatok megoldásában segíthetnek. Halad- 
junk a legegyszerűbbtől a bonyolultabbak felé! 


A MyInfo komponens 

A MyInfo ("MSWC.MyInfo") komponens eredetileg a W9x 
vonalhoz tervezett Personal Web Server-hez (az IIS kistest- 
véréhez) készült. A feladata az volt (lenne), hogy a webki- 
szolgálóra globálisan jellemző adatokat tároljon (tulajdo- 
nos, utcanév, stb.). Windows NT/2000-en eredetileg nem 
tárol semmit, de mi felhasználhatjuk, mint webszerverszer- 
te elérhető zsákot - míg az Application objektum tartalma 
csak az adott ASP-alkalmazásban érhető el, a MyInfo tar- 
talmát az egész webkiszolgáló, minden egyes webhely ír- 
hatja-olvashatja. Teljesítményokokból ASP alkalmazáson- 
ként azért csak egyet-egyet hozzunk létre, értelemszerűen 
a global.asa-ban: 


LOBJECT RUNAT-Server SCOPE-Application ID-oMyInfo 
PROGID-"MSWC.MyInfő:C/OBJECT5 


A MyInfo objektum minden bizonnyal a legegyszerűbb az IIS 
beépített objektumai közül, ugyanis egyetlen beépített jel- 
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lemzővel vagy metódussal sem rendelkezik. Legalábbis kez- 
detben. Az objektum ugyanis úgy veszi fel a jellemzőket, 
hogy értéket adunk nekik; ha egy jellemző nem létezik, nem 
hibát kapunk, csak egy üres stringet válaszként (myinfo.asp). 


If oMyInfo.Kutyam - "" Then 
oMyInfo.Kutyam - "Jerry Lee" 
End If 


A beállított értékek egy XML fájlba mentődnek el időnként 
(addig is a memóriában vannak). Ez a fájl Windows 2000 
alatt a WinNTYSystem32VnetsvWata könyvtárban található, 
myinfo.xml néven. Ha az oldal próbálgatása közben megnézzük, 
lehet, hogy még üres, de előbb-utóbb az objektumban beállí- 
tott értékek a lemezre kerülnek. A fájl tartalma ilyesmi lesz: 


SXML3 
SXKutyampJerry Leec/5 
cMyNameIszBond, James Bondc/5 


£/XML2 


Az, hogy az adatok mikor kerülnek (egyébként automatikusan) 
a memóriából a lemezre, nem szabályozható, ezért viseltessünk 
fenntartásokkal, ha fontos adatokat szeretnénk az objektumban 
tárolni (egy áramszünetet például nem biztos, hogy kibír). 


A Permission Checker komponens 

A Permission Checker (, MSWC.PermissionChecker") kompo- 
nens segít eldönteni, hogy az oldalt letöltő felhasználónak 
van-e hozzáférése egy adott fájlhoz. Ezt az információt sokol- 
dalúan felhasználhatjuk: gondoljunk csak arra, milyen diplo- 
matikus megoldás az, ha a felhasználó számára meg sem jele- 
nítjük azokat a linkeket, amelyekhez nincs hozzáférése. 

Az objektum egyetlen metódusa, a .HasAccess() igaz 
(True) értéket ad vissza, ha a paraméterként átadott fájl 
létezik, és az aktuális felhasználónak van joga azt olvasni. 
Minden más esetben a válasz False. A paraméter lehet ab- 
szolút és relatív elérési út (permcheck. asp): 


Set oPermCheck -— 


5, Server.CreateObject("MSWC.PermissionChecker") 


oPermCheck.HasAccess( "myinfo.asp" ) 


oPermCheck.HasAccess( "c:lboot.ini" ) 










Ahtto://www.netacademianet/mickzi 
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Permission Checker demo 


User: NETACADEMIÁAMA dministrator 
Access to myinfo.asp: True 
Access to ciboot.int: True 


Log on as a different user. 
2) 


http: /fvww.netacademia.netfmickipermcheck.aspologonzyes 4 





50 Az Administrator a boot.ini-hez is hozzáfér 
A Counters objektum 


A Counters (,, MSWC.Counters") objektum nevéhez híven szám- 
lálók készítéséhez használható. Minden számlálót a nevével 
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azonosítunk. A számlálók értéke - a MyInfo leírásánál emlí- 
tett fenntartásokkal - lemezre kerül, mégpedig a counters.txt 
fáljba, a szokott helyre. A példaprogram (counters.asp) bemu- 
tatja az objektum felhasználását. Mindenekelőtt, a Counters 
objektumból is egyet érdemes létrehozni, a global.asa-ban: 


LOBJECT RUNAT-Server SCOPE-Application ID-oCounters 
PROGID-"MSWC.Counters"5€/OBJECT2 


Ha ez megvan, jöhet a feldolgozás. Egy adott számláló értékét 
a .Get() metódus segítségével olvashatjuk ki. VBScript esetén 
a metódus által visszaadott értéket rögtön konvertáljuk szám- 
má (mondjuk a Clng() függvény segítségével), különben tech- 
nikai okokból előfordulhat, hogy hibát kapunk. Például: 


counterA - CLng( oCounters.Get("A") ) 


Az .Increment() metódus egy adott számláló értékét nö- 
veli eggyel, a .Remove() törli a számlálót (a fájlból is), 
míg a .Set() metódus segítségével az adott számlálót fix 
értékre állíthatjuk be. 


A Page Counter komponens 

A PageCounter komponens (, MSWC.PageCounter") oldalak 
letöltését hivatott számlálni - természetesen az értékek le- 
mezre is kerülnek, így nem vesznek el még váratlan leállás 
esetén sem. Mégpedig azért nem, mert a PageCounter ob- 
jektum esetében - az előzőekkel ellentétben - beállíthatjuk, 
mikor írja lemezre is az adatokat. Keressük meg a registry- 
ben a HKEY CLASSES ROOTWSWC.PageCounter kulcsot: 
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000000019 (25) 
a A PageCounter objektum beállításai: az adatok 
mentésének helye és a mentés gyakorisága a registry- 
ben beállítható 


Amint az látszik, a Save Count értéke 25. Ez azt jelenti, 
hogy a PageCounter 25 találat után írja lemezre az adato- 
kat (ez nem oldalanként 25, hanem összesen 25 találatot 
jelent). Ha ezt az értéket kisebbre (mondjuk 1-re :-) ) állít- 
juk, nem kell félnünk a váratlan adatvesztéstől (azt azért 
várjuk meg, míg az objektum újra betöltődik és az új értéket 
beolvassa a registryből, például egy IIS restart hatására) . 
Maga az objektum három metódussal rendelkezik 
(pagecounter. asp) : 

"0 .Hits() - paraméter nélkül az aktuális oldal találati számát 
adja vissza. Ha akarjuk, paraméterként megadhatunk más 
oldalt is (virtuális ASP path segítségével: ,,/dir/file.asp"). 
.Reset() - paraméter nélkül az aktuális oldal számlálóját 
0-ra állítja. Paraméterként itt is megadhatjuk egy má- 
sik oldal címét. 

.PageHit() - itt nincs mese: a metódus hívásának ha- 
tására az aktuális oldal számlálója eggyel nő. 

Ez az egyszerű kis számláló egy nagy hibával azért rendel- 
kezik: nem tudja megkülönböztetni az új látogatót a no- 
tórius refresh-nyomogatótól. Ha a valósághoz kicsit köze- 
lebbi adatot szeretnénk, ki kell találnunk valamit. Süssünk 


R 
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egy bélyeget a látogatók homlokára (na jó, nyomjunk sütit 
a szájukba, az mégiscsak humánusabb megoldás ... :-) )! 


Cookie segít a számlálásban 

A feladat tehát az, hogy mindenkit, aki egyszer már meg- 
billentette a számlálót, jelöljünk meg egy cookie-val, így 
legközelebb már felismerjük, és nem számoljuk be az új 
látogatók közé. (Azok a böngészők, amelyek nem támogat- 
ják a cookie-kat, továbbra is állandóan növelni fogják a 
számlálót, de bízzunk benne, hogy a többség nem idegen- 
kedik egy kis süteménytől.) Megjegyezhetnénk az IP címü- 
ket is, de a mai dinamikus IP címek, illetve proxyk és tűz- 
falak világában ennek már nem sok értelme lenne. 
Küldjünk inkább egy cookie-t, ami mondjuk egy évig érvé- 
nyes (pcount.asp): 


cz 
PAGEVERSION - 1 
sPageID - "counted:" § 
4 Reguest.ServerVariables ("SCRIPT NAME") 
nID - Reguest.Cookies( sPageID ) 
If nID - "" Then nID - 0 

If nID c PAGEVERSION Then "uj latogato 
Response.Cookies( sPageID ) - PAGEVERSION 
Response.Cookies( sPageID ).Expires 5 
4 DateAdd("y", 1, Now() ) 
oPageCounter.PageHit 

End If 


32 


Menjünk végig soronként a fenti példakódon: A PAGEVER- 
SION tartalmazza az oldal aktuális verzióját. Ez azért jó, 
mert ha az oldalon változtatunk valamit, és újra minden- 
kit szeretnénk számolni, elég lesz ezt az értéket megnö- 
velni. Azután: generálunk egy nevet a cookie-nak, ese- 
tünkben ez a ,counted:" szó és az adott oldal fájlneve, 
így nem keverjük össze, ha több oldalra is számlálót te- 
szünk majd. Ezt a nevet az sPageID változóban tároljuk. 
Kiolvassuk a cookie értékét; ha nincs ilyen, értéke nyilván 
üres string (nekünk jobb, ha 0), ha pedig van, akkor az az 
utoljára meglátogatott oldal verziószáma lesz. A cookie 
értékét az nID változóba tároljuk. 

Ha a kiolvasott érték kisebb, mint az aktuális verzió, ak- 
kor egyrészt jöhet a számláló növelése (oPageCounter. Pa- 
geHit), másrészt pedig mehet a süti. Beállítjuk az értékét, 
majd a lejárati idejét mondjuk egy évre (DateAdd("y", 1, 
Now())). És már készen is vagyunk! 


Fülöp Miklós 
mick 2netacademia.net 


[11 / icademia. ladatok/: 
"(21 http://msdn.microsoft.com/scripting/ . 
s; vbscript/doc/vsobjfilesystem.htm 

31 http://msdn.microsoft.com/library/ 

s psdk/dasdk/mdaodajx.htm 
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Az elmúlt két számban megismerkedtünk a MIME üzenetek 
néhány fontos tulajdonságával. Tudjuk, milyen korlátokat 
szab az SMTP protokoll, ismerjük a MIME karakterkészletekre 
és tartalomtípusokra vonatkozó bővítményeit; most végre kö- 
vetkezhetnek a több részből álló üzenetek, amelyek a MIME 
igazi erejét adják. Az egyes RFC-k címét nem írjuk le, min- 
den RFC ugyanúgy, az [1] módon leírt címmel érhető el. 


A MIME Browser 

Aki Windows 2000 operációs rendszerrel rendelkezik, a [2] cím- 
ről letöltheti a MIME Browser nevű programocskát, ami MIME 
formátumú levelek tartalmának vizsgálatára használható de- 
monstrációs eszköz. A telepítés után futtassuk a program- 
könyvtárban található regshell.vbs scriptet, ekkor az .eml fájlok 
(elmentett MIME formátumú levelek) kiugró menüjében megje- 
lenik a ,Browse MIME Structure" menüpont, amire kattintva 
elindul a MIME Browser, és megkísérli betölteni az adott állo- 
mányt. A cikk olvasása során ez az eszköz folyamatosan nagy 
segítséget nyújt majd a levélformátumok megértésében, el- 
lenőrzésében. Annak sem kell izgulnia, aki Windows 2000 híján 
nem tudja használni a programot, mert az újság hasábjain áb- 
rákkal megpróbáljuk szemléltetni a látnivalókat. Ugyaninnen, a 
[2] címről lehet letölteni a cikkben található példa-leveleket 
is, amelyeket bárki - még a MIME Browser hiányában is — ki- 
próbálhat. Az .eml fájlokra kettőt kattintva az alapértelmezett 
levelezőprogram megjeleníti a levél tartalmát, ha pedig Note- 
Pad-del megnyitjuk őket, tanulmányozhatjuk a forráskódjukat. 


Több részből álló üzenetek 

A MIME üzenet több részből is állhat. Az SMTP szabvány szem- 
pontjából persze továbbra is egyetlen, csupaszöveg állomány- 
ról van szó, a levél részekre bontását a szövegben található 
határolókarakterek (vagy inkább ,,határolómondat") segítik. 
Egy nagyon egyszerű, mindössze két szöveges részt tartalmazó 
MIME levél egyszerűsített forráskódja így néz ki (1.eml): 


From: Fulop Miklos cmickénetacademia.net5 
MIME-Version: 1.0 
Content-Type: multipart/mixed; 


boundary-"hatarolo-szoveg-0001" 


Ez egy magyarazo szoveg nem MIME programok 


reszere. Ha ezt latja, ideje haladni a korral! 


--hatarolo-szoveg-0001 


Content-Type: text/plain 
Ez az elso resz torzse 


--hatarolo-szoveg-0001 


Content-Type: text/plain 
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(III. rész) 


Ez a masodik resz torzse 


--hatarolo-szoveg-0001-- sZ) 


Ez az üzenet a demonstrációt leszámítva semmire sem hasz- 
nálható, mert itt csak a MIME megértéséhez szükséges fejléce- 
ket tüntettük fel. A szokásos és elhagyhatatlan , MIME-Versi- 
on" fejléc mellett feltűnik egy eddig ismeretlen tartalomtípus- 
főcsoport (Content-Type), ez pedig a multipart. Ez a tartalom- 
típus jelzi a program számára, hogy az üzenet tartalma több 
részből áll, azt fel kell darabolni és egyenként, mint üzenetré- 
szeket (angolul bodypart) kezelni. Az üzenetrészekről még ké- 
sőbb szólunk, előbb lessük meg a darabolás módját: A Con- 
tent-Type fejlécnek van egy boundary paramétere (esetünkben 
ennek értéke ,,hatarolo-szoveg-0001"). Ahol ez a szöveg feltű- 
nik az üzenetben (mindig egy sorban, két mínuszjel után, lásd 
0), ott képzeletben fogjunk egy ollót, és nyisszantsuk el a 
szöveget. A legelső előfordulás előtti részt (2) mi, MIME-ul 
tudók eldobjuk. Aki viszont nem ismeri a MIME-ot, annak ez 
fog legelőször megjelenni, ezért ez a hely ideális a régebbi le- 
velezőprogramoknak szóló kedves üzenet elhelyezésére. A több 
(nem feltétlenül két-) részből álló üzenet utolsó részének vé- 
gén található határolószöveg annyiban különbözik a többitől, 
hogy annak a végén is találunk két mínuszjelet (0). 


EL MIME Browser - 1.eml 
Fe View About... 
multipart/mixed  (charset ; encoding: 7bit; size: 589 " 1007) 





zlol2i 










(E) text/plain (charset iso-8859.2; encoding: 7bit: size: 1097 1952) 
(EJ text/plain (charset: : encoding: 7bit: size: 120 " 202) 


From: Fulop Miklos emick Énetacademia net 
MIME Version 1.0 

(Content-Type: multipart/móved; 
boundarye" hatarolo-szovég:0001" 







5 A levél a MIME Browserben. Jól látszik, hogy a levél 
két részből áll; és a részek text/plain típusúak 


Az üzenetrészek 

A szétszabdalt üzenet részei külön-külön egy-egy igazi, 
nagy" SMTP levélhez hasonlítanak. Mindegyik üzenetrész 
(bodypart) fejrészt (fejléceket) és törzset tartalmaz, a két 
fő összetevőt pedig egy üres sor választja el. Az üzenetrész 
fejlécei között most persze nem a teljes levélre, csak az 
adott üzenetrészre vonatkozó MIME-fejlécek találhatók 
(tartalomtípus, karakterkészlet, kódolás, stb.). Miután min- 
den üzenetrész saját fejlécekkel rendelkezik, semmi akadá- 
lya annak, hogy az üzenet egyik része mondjuk cirill betűs 
szöveg, a másik pedig mondjuk egy magyar nyelvű HTML 
dokumentum legyen. Sőt! Az üzenetrész önmaga is lehet 
egy több részből álló (multipart) üzenetrész, saját, egyedi 
határolószöveggel - ilyenkor fogjuk a kisollót, és az üze- 
netrészt tovább daraboljuk. Akármilyen bonyolult MIME-fát 
építhetünk, álljon itt egy valóságból kölcsönzött, bár nem 
az egyszerűbbek közül való példa (2.eml): 
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ETIKZZTTEZEE 
File View About... 


mulipaít/ signed. fcharset : encoding: 7bA: size: 78392 — 1007) 
Ég multipart/mixed  (charset : encoding: 7bit; size: 73465 " 942) 
A Ég multpart/relaled  (charset : encoding: 7bit: size: 46460 7 592) 
Ev Ég mulipatt/altermative . fcharset: : encoding: 7bit: size: 107312) 
(E) tex/plain. (charset íz0:8859-2; encodíng: guoled-printable; size 144 — OZ) 
EJ text/himi (charset: iso 88592: encoding: guoted-pintable; size 645 129 
3] image/peg  (charset: ; encoding: base64; size: 45121 583) 
applcalion/mswotd  (charset : encodng base64; size: 26774 7 3422) 
E appícation/x.pkcs7-signature . charset: ; encoding base64; size: 41057 52) 


lola 























5 HTML formátumú, beágyazott képet és egy Word 
csatolt állományt tartalmazó, végül digitálisan aláírt 
levél felépítése 


Gyakorlatlanok ne próbálják az ábrát rögtön, részletekbe 
menően megérteni - a migrén fájdalmas lehet, és ráadá- 
sul lassan is múlik el, - egyelőre a hierarchiát próbáljuk 
meg átlátni. Figyeljük meg a négy egymásba ágyazott 
multipart üzenetrészt, és azt, hogy ki kinek a gyermeke. A 
második , szinten" található multipart/mixed üzenetrész 
például egy Word dokumentumot és másik multipart üze- 
netrészt tartalmaz, ami egy újabb multipart-ból és egy 
JPEG képből áll - és ez még csak a hierarchia fele! 


Üzenetrész-fejlécek 

A multipart tartalomtípus is , csak" egy főcsoport, és ennek 
a főcsoportnak is több alcsoportja létezik. Mielőtt azonban 
a multipart-alcsoportokra rátérnénk, bemutatjuk a leggyako- 
ribb, multipart-alcsoporttól függetlenül használt fejléceket. 


A Content-Type üzenetrész-fejléc 

Ez talán a legfontosabb információ: az üzenetrész által hor- 
dozott adat típusát határozza meg (ami ugye lehet valame- 
lyik hagyományos, az előző számban már bemutatott tarta- 
lomtípus, vagy akár egy másik multipart üzenetrész is). Szöve- 
ges tartalomtípus esetén a legtöbb esetben ez a fejléc rejti 
az üzenetrészben használt kódtábla azonosítóját (charset): 


Content-Type: text/plain; 
charset-"iso-8859-2" 


A name paraméterben pedig gyakran hordozza az üzenet- 
rész által tartalmazott fájl eredeti nevét, például: 


Content-Type: application/msword; 


name-z"doci.doc" 


Végül ne feledkezzünk el arról, hogy a multipart tartalom- 
típus esetén itt kell megadnunk a darabolás helyét jelző 
szöveget (boundary): 


Content-Type: multipart/mixed; 


boundary-"hatarolo-szoveg-0001" 


A Content-Type fejlécnek e háromnál sokkal többféle para- 
métere lehet, ezeket a paramétereket mindig maga a tar- 
talomtípus határozza meg. A különböző multipart tarta- 
lomtípusok paramétereiről a megfelelő helyen mi is emlí- 
tést teszünk, egyéb esetben az RFC-k böngészése segíthet. 


A Content-Transfer-Encoding üzenetrész-fejléc 


Csakúgy, mint a teljes üzenetre vonatkozóan (lásd a teljes 
leírást az előző számban) , üzenetrész-fejlécként használva 
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is az üzenetrész-tartalom 7 bitre kódolásához használt 
módszert jelzi. Üzenetrészenként használva megoldható, 
hogy az üzenet szöveges részeit a Ouoted-Printable, míg a 
bináris részeket (mondjuk egy csatolt word dokumentu- 
mot) az ilyen tartalomnál hatékonyabb Base64 kódolással 
vigyük át. Fut még a 7bit kódolás is, ami a nemkódolást 


jelenti (ASCII szöveg esetén). Példák: 


Content-Transfer-Encoding: guoted-printable 
Content-Transfer-Encoding: base64 


Content-Transfer-Encoding: 7bit 


A Content-Disposition üzenetrész-fejléc 

No, ez a fejléc már teljesen új. Az üzenetrészre aggatott Con- 
tent-Disposition fejléc jelzi, hogy az egy csatolt állomány (ez 
esetben értéke attachment), vagy a levélben valahol felhasz- 
nált komponens (ilyenkor inline). Az inline típusú üzenetrészt 
a levelezőprogramok elvileg nem jelenítik meg, mint csatol- 
mányt. Próbáljuk csak ki, nyissuk meg a 3.eml példát! A leve- 
lezőprogram a három üzenetrészből az elsőt, a levél törzsét 
megjeleníti; a másodikat csatolt fájlként jelzi (kattintással 
megnyithatjuk, ha akarjuk), míg a harmadik ismét, felhaszná- 
lói közbeavatkozás nélkül látható (hiszen ,, része" az üzenet- 
nek). Ha a Content-Disposition értéke attachment, akkor a 
fájl későbbi kezelésére vonatkozó információs paramétereket 
is tartalmazhat: mindenekelőtt a fájl nevét (filename), eset- 
leg a méretét, vagy a létrehozásának dátumát, például: 


Content-Disposition: attachment; 


filename-"1.txt" 


Ebből tudja a levelezőprogram, mi volt a csatolt fájl 
eredeti neve. Ha ez a paraméter hiányzik, a program 
kénytelen a hasára csapni; ilyenkor kapunk ilyen fájl- 
neveket, hogy: att00891.txt vagy hogy att00915.gif. 
Hogy a kiterjesztést honnan tudja mégis? Ennek meg- 
fejtése házi feladat! 


Nos körülbelül ennyit az általános üzenetrész-fejlécekről. 
A továbbiakban a különféle multipart-tartalomtípusokról, 
és az általuk használt, speciális üzenetrész-fejlécekről ér- 
tekezünk. Mielőtt beleugranánk a mélyvízbe, ellenőrizzük 
az általános üzenetrész-fejlécekről összegyűjtött tudásun- 
kat a 4.eml példa segítségével! 





CSAT TJZTEZ EZEN 
File Va Aba. 


féz szsatmased fehaset ; encodng 752 sze 2056 — 10027 

(MA) teat/olan feharset is0.8853-2; encodng 7b; size: 124 — 62) 

TI] text/glan fchatset : encodng avoted gintable: size: 2257 1139 
image/gi lehamet : encodáng base64; size: 12497 6120 


DNETETSTETSE ERTE TTT 





Cortert-Type teszt 


Ez egy egyszeru, szoveges ASCII torzs 








o Egyszerű, csatolt fájlokat tartalmazó levél — figyel- 
jük meg az üzenetrészeknél használt különféle kódolási 
módszereket (encoding) 
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SZABVÁNYOK MIME - LEVELEZÉS AZ 
A multipart-alcsoportok 

Futólag már említettük, hogy a multipart tartalomtípus-fő- 
csoport különféle alcsoportokat tartalmaz. Az rendben van, 
hogy az üzenet több részből áll, de van-e a részeknek vala- 
mi közük egymáshoz? Az alcsoport szerepe, hogy megjelöl- 
je az általa tartalmazott üzenetrészek egymáshoz való vi- 
szonyát. Mindegyik tartalomtípusnak különleges szerepe 
van, és a legtöbb saját üzenetrész-fejléceket is használ. 


A multipart/mixed tartalomtípus 

A legáltalánosabb, legegyszerűbb és talán leggyakoribb típus 
(RFC 1521). A részeknek nincs szorosabb közük egymáshoz, 
hacsak nem az, hogy egy üzenetbe kerültek. Tipikus példa az 
egyszerű, csatolt állományokat tartalmazó üzenet (mint az 
eddigi példák többsége, például a legutolsó 4.eml is). 


A multipart/alternative tartalomtípus 

Ez egy nagyon érdekes típus (RFC 1521); szerepe a HTML 
levelek megjelenésével vált egyre fontosabbá. Az alterna- 
tív üzenetrészek ugyanazt tartalmazzák, különböző formá- 
tumban; közülük elég azt megjelenítenünk, ami a szívünk- 
nek kedves. Lássuk csak egy egyszerű, tisztán szöveget 
tartalmazó, de HTML levél felépítését (5.eml): 


-zJDI2d 





mulipanZaltemative [charset ; encodng: 7bi; size: 1125 7 10077 
(új) text/plain. (charset is0.8859.2: encodíng: guoted pintable; sze: 1177 1034 
ÉJ text/html. (charset: iso.8859-2; encoding: gyoted-printable; size: 470 7 422) 





a HTML levél, text alternatívával 


Egy jólnevelt HTML levél egy text/plain és egy text/html részt 
tartalmaz, ahol a text/plain üzenetrész a HTML rész szöveges 
kivonatát tartalmazza. Mi dönthetünk: ha nem akarjuk a 
HTML-t megjeleníteni, ott a szöveges verzió. Ez persze azt je- 
lenti, hogy a levél tartalma redundáns, viszont levelezőprog- 
ram-barát. Látható, hogy az üzenet teljes terjedelmének 
429-át a HTML üzenetrész teszi ki, a plusz szöveges rész csak 
további 10990 (a 100-ból fennmaradó részt a levél SMTP fejlécei 
képezik; ez az arány persze levelenként eltérő). A többlet ter- 
helés tehát jelen van, de általában nem számottevő. 

Fontos megjegyezni, hogy az alternatív tartalomtípus sem csak 
két verziót tartalmazhat; előfordulhat akár egy text-rtf-word6- 
word2000 csomag is. Az RFC 1521 mindössze annyit kér, hogy a 
legegyszerűbb formátum (esetünkben a sima szöveg) legyen a 
levélben legelöl, majd növekvő bonyolultsági sorrendben követ- 
hetik a további verziók. Így sokkal könnyebb a feldolgozás azok 
számára, akik csak valamely , gyengébb" formátumot ismerik. 


A multipart/related tartalomtípus 

Egymáshoz kapcsolódó üzenetrészek (általában az egyikben 
hivatkozás történik a másikra) azonosítója (RFC 2112). Egy- 
szerűbb megérteni, ha magunk elé képzelünk egy HTML üze- 
netet, ami egy képet tartalmaz (tehát nem csatolt állomány- 
ként, hanem beillesztve). A kép is az üzenetben utazik, a 
HTML kódban pedig speciális hivatkozás szerepel a helyén. 
Ha megnyitunk egy ilyen levelet, a kép az üzenet belsejében 
jelenik meg, és nem érjük el, mint csatolt állományt. Termé- 
szetesen maga a HTML rész sem mint tiszta HTML, hanem 
mint komplex multipart/alternative rész utazik (lásd az előző 
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INTERNETEN 


(III. RÉSZI 


bekezdést); egy beillesztett képet tartalmazó HTML levélben 
tehát már felismerhetjük az első hierarchikus jellemzőket: 





EX MIMEBrawser -6-eml 


lola 





muípart/related . (charset: ; encoding: 7bit; size: 5435." 10022) 
ÉG multipart/altemative  (charset: ; encoding: 7bit; size: 535 7 1072) 
text/plain (charset: is0-8359-2; encoding: 7bit; size: 87" 27) 
€) text/himi . (charset: íso-8859-2: encoding: 7bit; size: 164." 322) 
image/ípeg . (charset: : encoding: base54; size: 4554 " 8479 





a HTML levél, melyben kép is van 


Egy kérdés nyitott maradt: arról volt szó, hogy a HTML tar- 
talom hivatkozik a levélbe ágyazott képre. Pontosan ho- 
gyan is történik ez? Lássuk a 6.eml forrásának erre vonat- 
kozó részeit (mondjuk a HTML üzenetrészt teljes egészében 
9, és a kép üzenetrészének elejét 0): 


pm) 


Content-Transfer-Encoding: 7bit 


--hatarolo szoveg 0001 


Content-Type: text/html 


(,xHTML:CHEAD2C/HEAD2 

LBODY5 

LxIMG src-"cid:content id 000175 
£/BODY3c/HTML2 


-ehatarolo szoveg 0001-- 


--hatarolo szoveg 0000 


Content-Type: image/jpeg; 


name-"MSGIRL2. jpg" 
Content-Transfer-Encoding: base64 
Content-ID: ccontent id 00012 zzz) 


/9j/4ARAOSKZIRgABAOEASABIAAD/ 2WBDAAYEBOYF. . . 
FhYaHSUfGhsjHBYWICwgIyYnKSOPGRB8BtMCOOMCUO . . , 


A határoló szövegeket próbáljuk meg magunk értelmezni, 
de ehhez a teljes kódot látni kell! (Annyit segítek, hogy a 
.0001 végű a multipart/alternative, a 0000 végű pedig a 
multipart/related határolószövege.) A lényeg most az üzenet- 
be ágyazott elemek , címzése". Figyeljük meg, hogy a képet 
tartalmazó üzenetrész tartalmaz egy Content-ID fejlécet CO: 


Content-ID: ccontent id 00015 


A fejléc értéke az adott üzenetrész azonosítója (a kacsa- 
csőrök nem tartoznak az azonosítóhoz). 
A HTML kódban pedig a kép forrásaként nem internetes 
URL (például http://...), hanem egy speciális címzés sze- 
repel (egyébként ez is egyfajta URL) O: 


SIMG src-"cid:content id 0001"5 


A megjelenítéskor a levelezőprogram a cid: bevezetőből 
tudja, hogy a hivatkozott elemet az üzeneten belül, a 
megadott Content-ID alapján kell megkeresnie. 

A multipart/related tartalomtípusnak van egy kötelező 
type paramétere, ami a ,gyökérként" feldolgozandó üze- 
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netrész tartalomtípusát tartalmazza (annak az üzenetrész- 
nek, amelyre nem hivatkoznak, hanem ő hivatkozik); ese- 
tünkben ez a multipart/alternative: 


Content-Type: multipart/related; 
type-"multipart/alternative"; 


boundary-"hatarolo szoveg 0000" 


A tartalomtípus többi paramétere opcionális, akit érdekel, 
olvassa el a témáról szóló RFC 2112-t. 


A multipart/signed és multipart/encrypted tartalomtípusok 
Digitálisan aláírt (signed) / titkosított (encrypted) üzene- 
tek (RFC 1847). Kezdjük a végéről: a multipart/encrypted, 
azaz titkosított többrészes üzenet, amely mindig ponto- 
san két részből áll. Az első a titkosításhoz szükséges 
kontrollinformáció, a második pedig maga a titkosított 
adatfolyam, amely application/octet-stream (8 bites adat- 
folyam) tartalomtípust hordoz. A manapság használatos 
titkosítások esetén általában a multipart/encrypted tarta- 
lomtípus nem szerepel, az S/MIME levelezőprogramok 


elintézik a dolgot egyetlen önhordó (még csak nem is 
multipart) titkosított levéllel (amelynek tartalomtípusa ne- 
mes egyszerűséggel application/x-pkcs7-mime) . 

Viszont az aláírt levelek! A 7.eml egy egyszerű digitálisan 
aláírt szöveges üzenet. A multipart/signed is mindig pon- 
tosan két üzenetrészt tartalmaz. 


z DI 





mulípatt/signed  (charset dos síze: 471471 






e: 4109 " 872) 


a Digitálisan aláírt szöveges üzenet 


Ebből az első a digitálisan aláírt, ,védett" üzenetrész 
(bármi lehet, egyszerű szövegtől az összetett multipart üze- 
netrészekig); a második pedig az aláírás maga, tartalomtí- 
pusa az aláírás algoritmusától függ. Ha belenézünk a for- 
ráskódjába (most már ideje lenne letölteni azt a MIME 
Browsert, nem?) , a fő tartalomtípus fejlécénél ezt látjuk: 


Content-Type: multipart/signed; 
protocols"application/x-pkcs7-signature" ; 
boundary-"hatarolo-szoveg-0000" ; 
micalg-SHALl 


Jól látható a tartalomtípus három kötelező paramétere. Az 
egyértelmű határolószöveg (boundary) mellett meg kell 
adni a digitális aláírás protokollját (protocol, ez lesz a má- 
sodik üzenetrész tartalomtípusa is), valamint az ellenőrző- 
összeg képzéséhez használt algoritmus (Message Integrity 
Check Algorythm, micalg) nevét. A fejléc tanulsága szerint 
a példában látható digitális aláírás az SHA1 algoritmus se- 
gítségével készült. Ha az első, védett üzenetrészben bár- 
mit (akár egy üzenetrész-fejlécet is) megváltoztatunk, a di- 
gitális aláírás azonnal , elromlik" és kiderül a turpisság. 


A multipart/report tartalomtípus 


Bizonyára mindannyian kaptunk már valamelyik levelezőki- 
szolgálótól a levelünk sikertelen vagy akár sikeres kézbesíté- 
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sére vonatkozó válaszlevelet, esetleg visszajelzést arról, hogy 
a címzett elolvasta a levelet. Azt már kevesebben tudják, 
hogy ezeknek a leveleknek speciális formátumuk van, előse- 
gítve ezzel az ilyen üzenetek automatikus feldolgozását. 
Válasszuk ketté a multipart/report (RFC 1892) tartalomti- 
pust! Nézzük meg először, hogyan néz ki egy elolvasást 
visszaigazoló üzenet (read receipt, 8.eml): 


2JOI21 





BIMIMEBrowser - 8eml 
File View About... 





mudlipattrepont  (charset: ; encodng 7bit: size: 1166 — 10059 
a s e. 150 8959.2. ösát docAuthor] s; 








IBODYPART INFORMATION: 4 
Content Type: message/díisposítton- notification 

Encoáng 7bi 

fCharset 

FieNamer 

[Content Dispositiorc iníne 7 
Size: 0.27 kByte (279 bytes) 

Child parts: 0 


JDECÖDED TÖNTENT: 

Final Recipient ic822.mick Enetöcösdemi. 

DrignatMeszage ID: elsstótedlácítözetászOtONd0-Sebemágtó 
Dispostionc manuakactionzMDN-sent-manually: displayed 





Bodypatt Information 4 





a Read receipt 


A multipart/report első tagja egy egyszerű szöveges üzenet 
arról, hogy elolvastam a magamnak küldött levelet. A má- 
sodik tag pedig egy message/disposition-notification tarta- 
lomtípusú üzenetrész (RFC 2298), aminek tartalma elárulja 
az eredeti üzenet azonosítóját (a levelezőprogramunk tudná 
követni, hogy melyik levélről érkezett visszajelzés!) , hogy vé- 
gülis ki kapta meg az üzenetet (például ha átirányítás tör- 
tént), illetve a visszajelzés elküldésének körülményeit (nem 
automatikusan, hanem az én megkérdezésemmel történt) . 

Lássunk egy kézbesítési üzenetet (Delivery Report) , amely- 
ben a levelezőkiszolgálónk értesít róla, hogy a Télapónak 
egyelőre nem a NetAcademia-hoz kell címezni a leveleket: 


alol 


PI MIME Browser - Delivery Status Notification (Fallüt ejtem 











máltipatt/report feharset ; encoding 7bt size: 1970." 10027 
a testzolain e prgadet dul7 szeren. 





síze: 245 1239 





Hi message/oS22 fchartet : encoding. 7bt. size: 819 " 4254) 






IBOOVPART IHFORMAÁTION: 
ICortent Type message/delveny-státus 
lEnccdng. 7bi 

fCharzet 
iFdeName: 
[Content Disposítort 

Size: 0.27 köyte (276 bytes) 
jhid parts: 0 

IDECODED CONTENT: 



















dnszwáght 
fvalDate: Tue. 12Jun 2001 00.57-55 50200 
IFinakftecipient. HegZZtelapolönetacademia net 
fölled 








f 
i 





o A Télapó nem nálunk dolgozik... 


Az első rész itt is egy szöveges üzenet a felhasználónak. Az 
üzenetben szerepel még a szóban forgó levél egy-az-egyben 
(message/rfc822, lásd RFC 1521), valamint maga a kézbesí- 
tésről szóló üzenet (message/delivery-status, RFC 1894). 
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SZABVÁNYOK bb 


Most lapozzon vissza a 30. oldalra és tekintse meg még 
egyszer azt a bizonyos HTML levelet, amely beágyazott képet és 
egy csatolt Word dokumentumot tartalmaz, és a végén még jól 
alá is írtuk. Ugye, hogy mégsem annyira bonyolult? 


Egy csendes megjegyzés: a MIME annyira jól ki van ta- 
lálva, hogy az is képes a leveleket olvasni, aki kényte- 
len csupán karakteres (linux/unix) környezetben dol- 
gozni. Még a fenti, igencsak összetett példa is tartal- 
maz tisztán szöveges összetevőt! Mindössze egy rendes, 
MIME-kompatíbilis levelezőprogram kellene hozzá... 


Az MHTML dokumentum 

Egy érdekességet szeretnék mutatni a MIME-ról szóló cikkso- 
rozat végén, aminek érdekes módon a levelezéshez semmi, a 
MIME-hoz viszont annál több köze van. A most leírtakat az 
Internet Explorer 5.0 vagy újabb változatának felhasználói 
már ismerhetik (illetve ha még nem ismernék, akkor kipróbál- 
hatják), aki nem rendelkezik ezzel a verzióval, annak itt az 
ideje frissíteni. Kezdjük az alapproblémával: egy HTML oldal 
tartalmát szeretnénk elmenteni, későbbi olvasgatásra. A 


klasszikus módszer valami ilyesmit eredményez: 









CI wa. garfield, com, fies 
[éj www, garfield, com.htm 







23KB HTML Document 







savehtmi 





Select an item to view its 
description. 


See also: 
Mv.Documentz 
(Wv. Network Places 
Mv.Computer 

4 31 
a Ha egy weblapot elmentünk, a HTML fájl mellett a 
ssallangok" egy külön könyvtárba kerülnek 


Van eset (a Garfield például pont ilyen :-) ), hogy nem 
gond, sőt előny, ha egy weblapon található képek, grafi- 
kák külön-külön a lemezre íródnak. Máskor azonban kifeje- 
zetten macera a fájl és a hozzá tartozó könyvtár együttes 
másolgatása (próbáljuk ki, és hozzunk létre egy könyvtárat 
és egy HTML fájlt, mint a fenti példában; azután töröljük ki 
a HTML fájlt, és csodák csodájára a Windows a megkérdezé- 
sünk nélkül törli a (szerinte) hozzá tartozó könyvtárat is .. 
khm..). Egyszóval ezzel sokszor csak a baj van. 

Nem lehetne összecsapni az egészet egyetlen fájlba? (Na 
jó, nem a tömörítésre gondolok...). Dehogynem. Az Inter- 
net Explorer 5.0-tól kezdve a Save As... ablakban egy ed- 
dig ismeretlen, új formátumot is kiválaszhatunk: 





a IE5-től kezdve Garfield-ot .mht-ba is menthetjük 
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"Web Archive, single file" (webarchívum, egyetlen fájl) - 
mondja a magyarázat az .mht kiterjesztés mellett. Nosza, 
próbáljuk ki! A mentés végén valóban egy fájl keletkezik 
(néhányat a [2] címről is letölthet a lelkes Olvasó). Hurrá! 
Semmi sallang! 


Na de mi köze ennek a MIME-hoz?! 
Rögtön meglátjuk, ha egy .mht fájlt a jó öreg MIME Brow- 
ser-be vontatunk (persze akkor is kiderül a turpisság, ha 
egyszerűen megnyitjuk, mondjuk NotePad-del). Az .mht fáj 
(MHTML dokumentum) nem más, mint egy MIME formátu- 
mú HTML , levél", beágyazott objektumokkal. 





TESZTEN ETEET] EY zlOl2d 


Fde Edit Format Help 





From: csaved by Microsoft Internet Explorer 57 
Subject: Official Site For Garfield And Friends 
ate: Mon, 18 Jun 2001 23:12:38 40200 
IME-Version: 1.0 
ontent-Type: multipart/related; 
Boundarya tsai -NextPart. 000. 0000. O1COFB4C, ZAEJA9AO" 
types"text/htmi" 
[X-MimeOLE: Produced By Microsoft MimeOLE VS5.50.4522.1200 








írhís ís a multí-part message in MIME format. 


[------ e. NextPart, 000. 0000. O1COFB4C. 2AE3A9AD 
ontent-Type: text/htmi; 

charsete"windows-1250" 
ontent-Transfer-Encoding: guoted-printable :1 





a Az .mht fálj valójában egy HTML levél, az M betű a 
MIME-ot jelképezi: MHTML Document 


Még feladója, feladási dátuma és témája is van! És hogy 
mi van belül? Rögtön meglátjuk, ha megnyitunk egy ilyen 
fájlt a MIME Browserrel: 





ETKHITTTETTTTTT BEBET 


File View About... 


mulipart/related . fcharset : encodng 75: síze: 140382 — 10079 2] 
text/html. (charset: windows:1250; encoding: guoted-pintable; size: 23897 173) 





image/gil  (charset: : encoding: base64; síze: 10450" 77) 
image/gi . [charset: ; encoding: base64; size: 321." 029 
image/gi . [charset ; encodng: base64; size: 282 " 07) 
image/gil  (charset: : encodng base64; size: 7516" 527 
EETSTHETTATE ESETT pintable 





e: 27328 — 192) I 
appkcation/ejavascipt [charset: ; encoding. guoted-prirtable: size: 11477 129 s 
Sze: 4,75 köyte (4 869 bytes) 2] 
fehid parts: 0 
CODED CONTENT: 
ISTYLE typetextcss .standard ( 
FONT-SIZE: x-small; COLOR: blsek; FONT-FAMILY: Aral, Verdana, Geneva, Helvetka, sans-seri 








4 
[normal jngut ( 

FONT-SIZE: o-small; COLOR: $000000; FONT-FAMILY: Verdana, Geneva, Arial, Helvetica, sans- 5] 
[odypart information 





4 


a A Microsoft Magyarország elmentett weblapja a MI- 
ME Browserben 


Az ábrán a Microsoft Magyarország .mht-ba mentett főlapjá- 
nak kicsit kozmetikázott képe látható (az itt láthatónál sok- 
kal több kép van a fájlban, de ez ne zavarjon meg senkit). Az 
üzenet típusa értelemszerűen multipart/related (aki nem érti 
miért pont ez, lapozzon vissza); az első elem természetesen 
maga a HTML kód, majd azt követik szépen a hozzá kapcso- 
lódó üzenetrészek: képek, stíluslapok, javascript-darabkák. 


Fülöp Miklós 
mick Onetacademia.net 


A cikkben található URL-ek: 
[1] RFC xxxx: http://www.ietf.org/rfc/rfcxxxx.txt 
[2] http://technet.netacademia.net/download/MIME 
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Transact SOL 


. (VIII. rész) 


Bevezetés 

Fejlesztői szemmel nézve az SOL Server 2000 egyik legna- 
gyobb újdonsága az XML támogatás megjelenése volt. A ter- 
mék megjelenése óta eltelt több mint egy év, és természete- 
se nincs megállás, készül a következő verzió, aminek Yukon a 
kódneve, és a pletykák szerint a felhasználása jelentősen túl- 
mutat majd a jelenlegi verzióén. De az SOL 2000-et sem 
hagyták magára, újabb és újabb (ingyenes) kiegészítések ké- 
szülnek hozzá, amelyek segítségével újabb képességekkel ru- 
házható fel a szerverünk. Ezeket, és a termékben már eleve 
meglevő tudást járjuk körbe ebben a cikkben. 


Egy hétköznapi probléma 

Informatikai sznob divat vagy valóban hasznos segítség az 
XML támogatás az SOL Serverben? Aki volt a május végi ma- 
gyar .NET fejlesztői konferencián, az láthatta, hogy a transz- 
parenseken nagyobbak voltak az XML feliratok, mint a .NET- 
et hirdető igék. Az XML fenekestül felforgatja, átalakítja azt 
a képet, ahogyan az együttműködő rendszereket látjuk és 
programozzuk, és az elosztott rendszereket tápláló egyik leg- 
főbb bástyánk, az SOL Server sem térhetett ki a változás elől. 
Egy egyszerű és mindennapi példán keresztül megvilágítom, 
hogy mennyivel egyszerűbbé válik az életünk, ha az adatain- 
kat XML folyamként is kinyerhetjük az SOL Serverből. 

Legyen a feladatunk egy webalkalmazás megírása, amely SOL 
Serverből származó információkat jelenít meg egy ASP alapú 
weblapon. A szemléletesség kedvéért tegyük konkréttá a pél- 
dát. A megjelenítendő információ egy-egy fejlesztői tanfolyam 
eírása. Egy tanfolyamhoz nagyon sokféle információ kapcsoló- 
dik, - a tanfolyam leírásán keresztül a képzést tartó oktatók 
neve, képzettsége, a helyszín, időpontok, szabad helyek száma, 
satöbbi. Mivel az adatbázisban nem csak egy tanfolyamot táro- 
unk, ezért az adatbázis sok táblából fog állni, rendesen norma- 
lizálva van, így minden információt csak egyszer kell letárolni. 












































a Tanfolyamokat leíró adatbázis-séma 





Az ábrán láthatunk egy a problémára viszonylag részletes 
eírást nyújtó adatbázist. Látható, hogy a központi tábla a 
Course, és az összes többiben található információ erre a 
táblára illeszkedve épül fel. A feladat tehát az, hogy egy 
adott kurzussal kapcsolatos minden információt szedjük 
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össze a táblákból, és jelenítsük meg egy weblapon. 

Mit jelent az, hogy összeszedni? Milyen művelettel nyerhe- 
tőek ki egy adott tanfolyamhoz tartozó járulékos informá- 
ciók? Természetesen JOIN-nal, remélem, nem leptem meg 
senkit. Azaz összekapcsolom a táblákat a diagramban is je- 
tölt kapcsolatok mentén, és máris kész egy olyan ered- 
ményhalmaz, ami könnyen megjeleníthető. 

Biztos ez? Sajnos nem. Nem kell hozzá nagy képzelőerő, hogy 
kitaláljuk, az így összekapcsolt tábla pókhálóból nagyon sok sor 
fog legenerálódni amiatt, hogy az eredetileg hierarchikus infor- 
mációt síkba kiterítve tudjuk csak visszaadni. Az eredményhal- 
maz kétdimenziós, tábla szerkezetű, ha tetszik, ha nem. 
Például minden tanfolyam annyiszor fog megjelenni a listá- 
ban, ahány alkalommal megrendezzük, szorozva ahány okta- 
tó tartozik hozzá, szorozva ..., azaz a szimpla JOIN-ok így, 
ebben a formában nem megfelelőek a feladat megoldására. 
Azt nem mondom, hogy az így nyert hatalmas eredményhal- 
mazból nem lehet kiszedni a számunkra értékes infókat pél- 
dául egy intelligens script segítségével, de a kódspagetti 
(programnak nem nevezném) áttekinthetetlen, karbantartha- 
tatlan lesz, nem beszélve az indokolatlanul nagy eredmény- 
halmaz okozta felesleges erőforráspazarlásról. 


Hierarchikus kétdimenziós tábla? 

Valahogyan úgy kellene felépíteni az eredményhalmazt, hogy 
az tükrözze az eredeti információ belső szerkezetét. Menni 
fog? Kicsit körülményesen, de igen. A vezérfonalunk az lesz, 
hogy úgy építünk fel egy táblát, hogy a sorok a hierarchia 
bármely szintjén levő információt meg tudják jeleníteni, és 
az első két oszlopot használjuk fel a hierarchia leírására. Pél- 
dául ragadjuk ki a Course, CourseTrainer, Trainer táblákat. A 
Course egy tanfolyam főbb adatait tartalmazza, a Trainer az 
oktatókat tároló tábla, míg a kurzusok és az oktatók közötti 
viszony leírására szolgál a CourseTrainer nevű, több-több 
kapcsolatot létrehozó kapcsolótábla. Lássuk a három tábla 
tartalmát összegyúró lekérdezést: 


--Kurzus szekció 


SELECT 
Ü as Tag, 
NULL as Parent, 


Course.CourseID as (Course!l!CourseIDJ, 


Course.Title as [(Course!l!CourserTitlej, 
NULL as [Trainer!12!1TrainerNamej 
FROM 
Course 
WHERE 


Course.CourseID IN ("2073", "1913") 
UNION ALL 
--Trainers szekció 
SELECT 

2 
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1, 
Course.CourseID, 
NULL, 
Trainer.LastName t " ! 4 Trainer.FirstName 
FROM 

Course 
INNER JOIN 

CourseTrainer 
ON 

Course.CourseID - CourseTrainer.CourseID 
INNER JOIN 

Trainer 
ON 

CourseTrainer.TrainerID - Trainer.TrainerID 
WHERE 

Course.CourseID IN ("2073", "1913") 
ORDER BY 


(Course!1!CourseID], [Trainer!2!TrainerName] 


A kimenet: 






9-7 a fdnazz J avalen 

























7 
1 
Ce FT] 





A kétféle jellegű adathalmazt a UNION ALL operátorral 
kapcsoltuk össze. A Tag nevű oszlop tartalmazza azt, hogy 
az adott sor a hierarchia hányadik szintjén helyezkedik el. 
A két 1-es Tag-ű sor a hierarchia legfelső elemei, mindket- 
tő egy tanfolyam címét és kódját írja le. Látható, hogy e 
sorok szülője NULL, ebből tudjuk, hogy ők a gyökérelemek. 
A 2-es Tag-el rendelkező sorok egy adott tanfolyam okta- 
tóit reprezentálják. Ezek szülői az 1-es Tag-ű sorok, azaz a 
megfelelő tanfolyamok. Azokban a mezőkben, amelyek 
nem tartalmaznak értelmes információt (például az oktató- 
kat tartalmazó sorok tanfolyamcímet tartalmazó oszlopa), 
oda NULL-t generálunk, jelezve, hogy itt nincs értelmes in- 
formáció. A lekérdezés végén látható ORDER BY azért fon- 
tos, hogy az adott tanfolyamhoz tartozó oktatókat mindig 
megtaláljuk közvetlenül a hozzátartozó tanfolyamsor után. 
Az oszlopoknak elég vad, de szisztematikus neveket ad- 
tam. A név első része a forrástábla neve, a felkiáltójel utá- 
ni második rész a hierarchia szintje, azaz a sorban találha- 
tó információhoz kapcsolódó Tag értéke, a harmadik pedig 
egy beszédes név az oszlop tartalmára utalva. 

Ennek a kissé nehézkes, de következetes oszlopnévkódolás- 
nak az az előnye, hogy a kapott eredményhalmazt egy meg- 
felelően megírt értelmezőprogram felolvashatja, értelmezhe- 
ti, és anélkül felépítheti az eredeti hierarchiát, hogy bármit 
is tudna a bejövő adatok szerkezetéről vagy értelméről. Azaz 
írhatunk egy rekurzív táblafelolvasó-fabejáró függvényt, 
amely elkezdi felolvasni a sorokat, és a Tag illetve Parent 
oszlopokban található értékek mentén navigálva kiolvassa a 
megfelelő oszlopokat, és azt megjeleníti, mondjuk egymás- 
ba ágyazott táblázatokban, vagy egy fára felfűzve. 

Egy ilyen elven megírt program tetszőleges nagyságú és tartal- 
mű, de ilyen struktúrában összeállított eredményhalmazt képes 
kicsomagolni. Ez a program már sokkal átláthatóbb lesz, mint a 
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durrbele JOIN-nal generált tartalmat feldolgozó förmedvény, de 
még mindig problémás lesz a hierarchia különböző szintjein ta- 
lálható információk formázott megjelenítése. Természetesen 
ekkor az eddig általános értelmezőprogramunkat el kell kezdeni 
specializálni, és bele kell drótozni, hogy például a 2-es szinten 
található sorokat (ami az oktatókat tartalmazza) nem egy táb- 
lázatban, hanem egy vesszővel elválasztott listában kellene 
megjeleníteni. A sorokat bejáró ADO kódok elkezdenek keve- 
redni a ctablez, -TR2, cTD5, cSPAN: és egyéb HTML formázó 
elemekkel, és újra kész a kódspagetti. Ismerős ez, ASP progra- 
mozók? A kód fele Response.Write-tal van tele. 

Pedig olyan szépen indult az egész! Olyan zseniális lett az a kis 
táblánk. Mit vethetünk még be, hogy az eredményhalmaz bejá- 
rását végző kódról elfeledkezhessünk, és csak az adatok formá- 
zására legyen gondunk? Nos, ha az eredményhalmaz valamilyen 
módon XML formátumú lenne, akkor XSLT segítségével könnye- 
dén megformázhatnánk a forrásadatokat (lásd XML cikksorozat) . 
Hogyan tudunk ebből a szép kis táblából XML dokumentumot 
gyártani? Viszonylag egyszerűen. Felolvassunk az első sort. 
Látjuk, hogy a sor Parent mezője NULL, azaz ez egy gyökér- 
elem lesz. Az elem neve legyen a forrástábla neve, amit az 
oszlop nevének első darabjából tudhatunk meg (Course). En- 
nek megfelelően a generálandó XML tag valahogy így indul: 


cCourse 


Ehhez az elemhez két értékes információ társul, a tanfolyam 
azonosítója és címe. Ez az info még mindig az első sorban talál- 
ható. Illesszük ezeket be a Course elembe, mint attribútumokat: 
CourseID-"1913" 


Course CourseTitlez"Exchanging 


and Transforming Data Using XML and XSLT"5 


Mivel egyéb értékes adat már nincs ehhez a taghoz, lezár- 
hatjuk, és továbbmehetünk a következő sorra. 

A második sor Parent-je 1, ami nem más, mint az előbb 
megkezdett elem. Az ebben található információkat az 
előbb megnyitott Course elem gyermekelemeként vesszük 
fel, így reprezentálva a tábla által leírt hierarchiát. Az ok- 
tató nevét most is attribútumként tároljuk. A második sor 
feldolgozása után így néz ki a generált XML tartalom: 
cCourse CourseID-"1913" CourseTitle-"Exchanging 
and Transforming Data Using XML and XSLT"5 


cTrainer TrainerName-"Soczó Zsolt"/5 


A harmadik sor felolvasásával kiderül, hogy már nincs több 
oktató ehhez a tanfolyamhoz, mert újra egy 1-es Tag-ű sor 
jön, azaz egy újabb tanfolyam. Ekkor le kell zárnunk az első 
sornál megnyitott Course tagot, és elkezdeni egy következőt: 
cCourse CourseID-"1913" CourseTitle-"Exchanging 
and Transforming Data Using XML and XSLT"52 
dcTrainer TrainerName-"Soczó Zsolt"/5 
£/Coursez 


cCourse 
Innentől a Kedves Olvasó már könnyedén legenerálhatja 


papíron a maradék XML dokumentumtöredéket. Segítség- 
képpen itt a puska: 
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CCourse — CourseID-"1913"  CourseTitle-"Exchanging 
and Transforming Data Using XML and XSLT"5 
cTrainer TrainerName-"Soczó Zsolt"/5 
€/Coursez 
cCourse CourseID-"2073" CourseTitle-"Programming a 
Microsoft SOL Server 2000 Database"2 
dcTrainer TrainerName-"Fóti Marcell"/5 
cCTrainer TrainerName-"Soczó Zsolt"/5 


£/Coursez 


Ezt az itt végigjárt algoritmust bár elég munkás, de vi- 
szonylag egyszerű implementálni. De most tessék megka- 
paszkodni! Mi van, ha a korábbi lekérdezésünk mögé oda- 
biggyesztünk egy FOR XML EXPLICIT záradékot? 


ORDER BY 
(Course!1!CourseID], [(Trainer!2!TrainerName] 


FOR XML EXPLICIT 


Nos, az egyoszlopos eredményhalmaz egy szem oszlopá- 
ban egzaktul azt az XML dokumentumot kapjuk vissza, 
mint amit az előbb kézzel legeneráltunk. Viva SOL Server! 


FOR XML EXPLICIT 

Az SOL Server FOR XML EXPLICIT záradéka olyan szerkezetű táblát 
vár bemenetül, mint amit az előbb fabrikáltunk. Az SOL Server 
dokumentáció ezt univerzális táblának hívja, és pontosan úgy 
dolgozza fel a tartalmát, mint ahogyan az előbb mi is tettük. 
A példában a forrástáblák számunkra értékes információi attri- 
bútumként képeződtek le a cél XML adatfolyamba. Természete- 
sen ez csak egyfajta XML reprezentáció, például a kurzusról 
szóló adatok lehetnének gyermekelemek is. Szerencsére ehhez 
is kapunk támogatást. Ha az oszlopnév mögé egy felkiáltójel 
után kiírjuk az element jelzőt, akkor az oszlop nem attribú- 
tumként, hanem gyerekelemként jelenik meg a kimenetben: 


Course.CourseID as [(Course!l!CourselID] , 
Course.Title as 


(Course!1l!CourseTitle!elementj] , 


Sokkal bonyolultabb struktúrák is létrehozhatók az XML EXPLICIT 
segítségével, ehhez további jelzőket kell megadnunk az osz- 
lopok nevében. Részletek a Books Online-ban találhatók. 


XML nézetek 

A FOR XML EXPLICIT segítségével olyan XML reprezentációt 
hozhatunk létre, amilyet csak akarunk. Azonban 5-6 tábla fe- 
lett egyre áttekinthetetlenebb lesz az univerzális táblát lét- 
rehozó lekérdezés. A komplexitást táblakimenetű függvények 
felhasználásával némileg csökkenthetjük, például a fenti le- 
kérdezés hármas JOIN-ját berakhatnánk egy függvénybe. 

A gyakorlatban azonban általában fordítva történik egy 
XML kimenetű lekérdezés tervezése. Kapunk egy XML sé- 
mát, ami leírja a generálandó XML dokumentum szerkeze- 
tét, és ehhez kell kitalálni az ennek megfelelő XML tartal- 
mat generáló lekérdezést. Ekkor a séma alapján elő kell 
állítanunk az univerzális táblát, ami fárasztó, unalmas, és 
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eléggé intuitív feladat. Mi volna, ha segítene valaki eb- 
ben? Például, ha a kapott XML sémába beírhatnánk a 
megfelelő SOL táblák neveit, mezőit, és ez alapján valami 
legenerálná nekünk az univerzális táblát. 

Ki ez a láthatatlan segítő? ő az XSD annotált séma, vagy 
más néven XML nézet. 

Az XSD az XML Shema Definition [1] rövidítése, amely 
2001. március 31-e óta az aktuális XML sémaleíró ajánlás 
(azaz még nem szabvány, de már nyugodtan építhetünk rá, 
legfrissebb változata a május 2-i). Segítségével le lehet írni 
tetszőleges, jól formázott XML dokumentum szerkezetét. 
Hasonló sémaleírás már régóta létezik a Microsoft házatá- 
ján, amelyet XDR-nek (XML Data-Reduced) hívnak. Amikor az 
SOL Server 2000 elkészült, akkor még nem volt XSD, csak 
XDR. Emiatt az XML nézeteinket is csak XDR annotált séma- 
ként írhatjuk meg az SOL Server 2000 alatt. Aki éles környe- 
zetben tervezi XML nézetek használatát, az egyelőre marad- 
jon is ennél. Azonban utólag letölthető [2] és feltelepíthe- 
tő SOLXML2 kiegészítés az SOL Serverhez (Beta 1 állapotú), 
amely már XSD annotált séma támogatást is tartalmaz. 


Figyelem! 

Bár a dokumentációban nem találtam rá utalást, de 
az XSD annotált sémák csak akkor működnek az SOL 
Serveren, ha a Microsoft XML Parser 4.0 (Beta) [3] is 
fel van telepítve a gépre. 


Itt az ideje, hogy újra lássunk valami kézzelfoghatót. Ír- 
junk egy XSD sémát, ami specifikálja tanfolyamok listáját 
tartalmazó XML dokumentumok szerkezetét [4]. 


cxsd:schema 
xmlns : xsd-"http: //www.w3.org/2001/XMLSchema"5 
£xsd:element name-"tanfolyamok" 
type-"TanfolyamokTipus" /5 
Ixsd:complexType name-"TanfolyamokTipus"5 
£xsd:seguence? 
axsd:element name-"tanfolyam" 
type-"TanfolyamTipus" maxOccurs-z"unbounded"/5 
£/xsd:seguence2 
£/xsd:complexType? 
cxsd:complexType name-"TanfolyamTipus"5 
£xsd:seguences 
cxsd:element name-"Cim" type-"xsd:String"/5 
£xsd:element name-"Oktato 
typez"OktatoTipus" 
minOccursz"0" 
maxOccursz"unbounded" /5 
£/xsd:seguence? 
cxsd:attribute name-"Kod" type-"xsd:Sstring"/5 
£/xsd:complexType? 
Ixsd:complexType name-"OktatoTipus"5 
£xsd:seguences 
cxsd:element name-"Nev" type-"xsd:string"/5 
cxsd:element name-"Email" type-"xsd: string és 
£/xsd:seguencez 


£/xsd:complexType? 


£/xsd:schemaz 
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Erre a sémára illeszkedik például az alábbi dokumentum [4]: 


c?xml version-"1.0" encoding-"ISO8859-2"?5 
Stanfolyamok? 
Ztanfolyam Kod-"2063"5 
cCimintroduction to ASP.NETC/Cim 
SLOktatoz 
SNevPSoczó ZsoltcC/Nev2 
dcEmailszsolt.soczotnetacademia.netc/Email: 
£/Oktatoz 
£/tanfolyam 
Ztanfolyam Kod-"2124"5 
cCimpIntroduction to C$ Programmingc/Cim: 
LcOktatoz 
ZNev:Soczó ZsoltcC/Nev2 
dcEmailszsolt.soczognetacademia.netc/Email: 
£/Oktatoz 
SLOktatoz 
ScNev:3socic/Nev? 
SEmailssocignetacademia.netc/Email: 
c£/Oktatoz 
£/tanfolyam: 


£/tanfolyamok: 


Ami ebből könnyen kihámozható: az összetett, több gyer- 
mekelemet vagy attribútumot tartalmazó dokumentumré- 
szeket xsd:complexType elemekkel definiáljuk, amelyeken 
belül deklaráljuk a gyermekelemeit és attribútumait. Azaz 
kívülről befelé haladva, egyre inkább részletező módon ír- 
juk le a dokumentum szerkezetét. 

Hogyan házasítjuk össze ezt a sémát az SOL Server táblái- 
val? Ehhez bele kell írogatnunk a séma egyes elemeibe az 
SOL Server táblákra és mezőkre utaló kifejezéseket (innen az 
annotated schema elnevezés). A jelzéseinket egy külön név- 
térben hozzuk létre, így azok nem keverednek össze a séma 
eredeti elemeivel. A szükséges névtér az 


xmlns:sg1-"urn:schemas-microsoft-com:mapping-schema" 


amelyet - mint látható - általában az sgl névtér rövidítéshez 
rendelünk. Ha véletlenül az eredeti sémában már használják az 
sal névtér alias-t, akkor semmi gond, egyszerűen más álnevet 
adunk a fenti urn-el azonosított névtérnek, és a későbbiekben 
mindenhol ezzel hivatkozunk rá az sgl azonosító helyett. 

A sémában szereplő elemek és az SOL Server táblák közötti 
kapcsolatot az sal:relation attribútum segítségével teremt- 
hetjük meg. Például a tanfolyamelemnek megfelelő SOL 
Server tábla a Course lesz. Ennek megfelelően a tanfolyam- 
elemet így kell kiegészíteni: 


£xxsd:element name-"tanfolyam" 
type-"TanfolyamTipus" maxOccursz"unbounded" 


sal:relation-"Course" /5 


Miután a tanfolyamelemnek megjelöltük az SOL Server táb- 
la párját, a benne található elemeknek jelezni kellene, 
hogy melyik mezőkben találhatók meg a hozzájuk tartozó 
adat. Ebben az sgl:field attribútum lesz a segítségünkre: 
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Sxsd:element name-"Cim" type-"xsd:String" 
sal:field-"Title" /5 
Sxsd:attribute name-"Kod" type-"xsd:String" 


sal: field-"CourseID" /5 


Az SOL táblát meghatározza a szülőelem (tanfolyam) 
sgl:relation attribútuma, így azt a gyermekelemnél illetve 
az attribútumnál nem kötelező kiírni (bár kiírhatjuk, ha 
úgy jobban átlátható a nézet). 

Az Oktató elem már keményebb dió lesz. Ő a kapcsolótáblához, 
a CourseTrainer-hez tartozik, mert ahány bejegyzés van ebben 
a táblában (ahányan oktatnak egy tanfolyamot), annyi Oktató 
elemet kell létrehozni, benne a trainer-ek adatait tartalmazó 
gyermekelemekkel. A probléma az, hogy honnan tudja a sémát 
feldolgozó processzor, az SOLXML2 ISAPI alkalmazás, hogy mi- 
lyen kapcsolat van a Course és a CourseTrainer táblák között? 
Tőlünk, ha egy kicsit segítünk neki az alább látható módon: 


Zxsd:annotation: 

cxsd:appinfoz 
csal:relationship name-"CourseTrainersl" 
parent-"Course" 
parent-key-"CourseID" 
child-"CourseTrainer" 
child-key-"CourseID" /5 

£/xsd:appinfoz 


£/xsd:annotation? 


Ezt a blokkot a séma elejére írjuk. Az XML kimenetet generáló 
alkalmazás (XMLSOL2) ebből tudja, hogy a két tábla a CourseID 
mezőkön keresztül kapcsolódik egymáshoz, így a szükséges ki- 
menetet már elő tudja állítani egy egyszerű JOIN művelettel. 
Az Oktató elemnél megadjuk a forrástáblát a már ismert sgl:re- 
lation jelöléssel, és a kijelölt táblák közötti kapcsolatra pedig 
az sglirelationship attribútummal hivatkozunk, ahol az előbb 
létrehozott kapcsolat nevét adjuk meg: 


£€xsd:element name-"Oktatő 
type-"OktatoTipus" 
minoOccursz"O" 
maxOccursz"unbounded" 
sal:relation-"CourseTrainer" 


sal:relationship-"CourseTrainersil" /5 


Már csak egy lépés van hátra, amikor az oktatók neveit és 
e-mail címeit összekötjük a Trainer táblával. Ehhez egy 
újabb kapcsolatot kell kijelölnünk, amelyet a korábban lá- 
tott módon az cxsd:appinfoz elembe veszünk fel: 


£sgl:relationship name-"CourseTrainers2" 
parent-"CourseTrainer" 
parent-key-"TrainerID" 

child-"Trainer" 


child-key-"TrainerID" /5 


A kapcsolat a fantáziadús CourseTrainers2 nevet kapta. A 
név és e-mail mezőkben erre hivatkozunk: 
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€xsd:element name-"Email" type-"xsd:string" 





sal:relation-"Trainer" 
sal:relationship-"CourseTrainers2" 
sal:field-"Email" /5 


Az e-mail az Oktató elem gyermekeleme. A szülőelem más 
táblához (a CourseTrainer-hez) kapcsolódik, így minden 
gyerekelemnél, - az e-mail-nél is - meg kell adnunk a for- 
rástábla, a kifejtett kapcsolat és a mező nevét is. 

Minden elem megtalálta a párját az SOL Serveren, egyedül 
a tanfolyamok elem maradt árván. Ő egy állandó gyökér- 
elem, amelynek az értéke nem függ az SOL Server adatai- 
tól. Az ilyen elemeket az sgl:is-constant-"1" kiegészítéssel 
különböztethetjük meg a többi, dinamikus tartalmú elem- 
től. Ennek hatására az elem változatlanul megjelenik a ki- 
menetben. Nézzük meg az egész, készre annotált sémát is: 


cxsd:schema 
xmlns :xsd-"http: //www.w3.org/2001/XMLSchema" 
xmlns:sg1-"urn:schemas-microsoft-com:mapping-s- 
chema"5 
Exsd:annotation: 
£xsd:appinfo2z 
csgl:relationship name-"CourseTrainersl" 
parent-"Course" 
parent-keyz"CourseID" 
l child-"CourseTrainer" 
child-key-"CourseID" /5 
Ssagl:relationship namez"CourseTrainers2" 
parent-"CourseTrainer" 
parent-key-"TrainerID" 


child-"Trainer" 





child-key-"TrainerID" /5 
£/xsd:appinfoz 
I £/xsd:annotation; 
£Xxsd:element namez"tanfolyamok" 
type-"TanfolyamokTipus" sgl:is-constant-"1"/5 
Ixsd:complexType name-z"TanfolyamokTipus"5 
cxsd:seguences 
cxsd:element name-"tanfolyam" 
type-"TanfolyamTipus" maxOccursz"unbounded" 
sal:relation-"Course" /5 
£/xsd:seguences 
£/xsd:complexType2 
Xxsd:complexType name-"TanfolyamTipus"5 
£xsd:seguences 
€xsd:element name-"Cim" type-"xsd:String" 
sal:field-"Title" /5 
£Zxsd:element name-"Oktato 
type-"OktatoTipus" 
minoccursz"O" 
maxOccurs-"unbounded" 


sal:relation-"CourseTrainer" 





sal:relationship-"CourseTrainersl" /5 
£/xsd:seguences 
cxsd:attribute name-"Kod" type-s"xsd:String" 
sal:field-"CourseID" /5 
£/xsd:complexType? 
£xsd:complexType name-"OktatoTipus" 5 


! 
Sxsd:seguences 
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£xsd:element name-"Nev" type-"xsd:string" 
sal:relation-"Trainer" 
sagl:relationship-—"CourseTrainers2" 
sal:field-"FirstName" /5 
€xsd:element name-"Email" type-"xsd:string" 
sal:relation-"Trainer" 
sal:relationship-"CourseTrainers2" 
sal:field-"Email" /5 
£/xsd:seguence2 
£/xsd:complexType2 


£/xsd:schemaz 


Az XML nézet működés közben 

Hogyan tudjuk kipróbálni az XML nézetünket? 

Mindenekelőtt telepítsük fel az SOL2000 kiszolgálónkra az 

SOLXML 2 Beta 1-t [2], és az MSXML Parser 4.0 Techno- 

logy Preview-t [3]. Lehetőleg ne éles kiszolgáló legyen a 

célpont, mert abból bonyodalmak származhatnak. 

A telepítés után megjelenik egy Microsoft SOL Server XML 

Tools mappa a Start menüben. Ezen belül a Configure IIS Sup- 

port - Web Release 2 segítségével indul el az SOL Server XML 

támogatását konfiguráló konzol. Ebben a Default Web Site-ra 

állva jobb klatty, New Virtual Directory segítségével hozhatunk 
létre egy virtuális könyvárat a webkiszolgálón. Ezzel fogjuk 
elérni a SOL Servert HTTP protokollon keresztül. 

A virtuális könyvtár legfontosabb jellemzői: 

"0 Az ő neve, így fogunk rá hivatkozni az URL-ekben. 

"0 Az SOL kiszolgálóhoz kapcsolódáshoz szükséges felhasz- 

nálói azonosítás módja. 

Az adatforrás SOL Server neve és az elérni kívánt adatbázis. 

A HTTP-n keresztül engedélyezett műveletek. Ezek közül 

nekünk az XPath a legfontosabb, az kell az XML néze- 

tünkhöz. 

"0 A sémákat tartalmazó könyvtár elérési helye és virtuá- 
lis neve. Létrehozunk egy schema típusú virtuális ne- 
vet, jelen esetben views néven és a Path mezőben ta- 
lálható elérési útvonalat beállítjuk az XSD annotált sé- 
máinkat tartalmazó könyvtárra. 

Miután mindent sikeresen beállítottunk, és az annotált 

sémánk a fent beállított sémakönyvtárban van, már el is 

érhetjük a böngészőből: 


5 








harp.dot-netfnosghanljmewsísaldsamolesch ü 
- etanfolyamoks ül 


- etanfolyam Kodz"1016"5 
-CimsMastering Enterprise Development Using Microsoft Visual 


Basic 6c/Cim 
- cOktatos 
eNevszsoltc/Nev5 
cEmaiszsolt.soczogonetacademia net c/Email5 
c/oktatos 
e/tanfolyams 
- etanfolyam Kods"1017"5 
-CimoMastering Web Application Development Using Microsoft 
Visual InterDev 6/Cim: 
- cOktatos 
cNevoZsoltc/Nev: sz] 


[8 Done I [62 irtemet 








Az URL-ben az nasglkml a virtuális könyvtár neve, a 
views a sémákhoz létrehozott virtuális név, az 
sglgsampleschemaview.xml pedig az előbb megírt anno- 
tált séma. De mit keres a /tanfolyamok az URL végén? 

Az XML nézeteket szűrni lehet, a nézet neve után megadott 
XPath kifejezéssel (lásd XMLGessünk sorozatunk). A /tanfo- 
lyamok XPath kifejezés azt jelenti, hogy kérem az összes 
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gyökérszinten található tanfolyamok elemet. Ilyen egy van, a 
gyökérelem, azaz megkapjuk a teljes dokumentumot, szűret- 
lenül. És ha csak egy tanfolyam érdekel? Mi sem egyszerűbb: 









] Be Edt em Favortes Icds tb 














[doce fd rastlenep áz nanerimiremistseeem nemertem evezett ze] EJ ] 
B ctanfolyam Kods"21245 
-Cimsintroduction to Cé Programming for the Microsoft .NET Platform c/Cmo 
- cOktatoz ls 
cNevoZsolts/Nev2 
cEmalszsolt.soczoonetacademia.net c/email 
e/oktatoz 
eftanfolyams. § 
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Bonyolultabb kifejezéseket is megadhatunk, ám vigyázzunk, 
mert a kimenet egy XML dokumentum-töredék, ami nem biztos, 
hogy jól formázott lesz. Például lehet, hogy több mint egy gyö- 
kérelemet tartalmaz, amit nem tűr el az Internet Explorer sem: 





nt bem fevortes Ibah thb 
sdsen [ejts kinez azt rerezimem rmester en store ván STSSZ TT TISZTE] 7] EJ e 








The XML page cannot be displayed 
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Mivel gyakori, hogy csak töredékdokumentumot kapunk, 
jól jön az a lehetőség, hogy egy mesterséges gyökérelemet 
csempészhetünk be a legenerált XML dokumentum köré. 
Ennek érdekében a ?root-gyökérelemneve paramétert kell 
az URL végére írni: 












j 


Tsolte/hus 2 
úr 








Vajon hogyan generálja az XML nézetek adatait az SOL Ser- 
ver? Profiler-rel a színfalak mögé nézve gyorsan lebuktat- 
ható, hogy ő is bizony FOR XML EXPLICIT-et használ, ami- 
nek a forrásául szolgáló univerzális táblát (lásd előző rész) 
az SOLXML ISAPI alkalmazás állítja össze - helyettünk. 

A választás rajtunk áll: vagy használjuk közvetlenül a FOR 
XML EXPLICIT-et, vagy annotált XSD (esetleg XDR) sémát 
írunk. Akinek ismeretlen a séma felépítése, annak bizonyá- 
ra nagyon idegen és bonyolult az annotált séma készítése. 
Viszont aki ismeri, az többet nem fog bajlódni a FOR XML 
EXPLICIT univerzális táblájával. 


XML sablonok (XML Template) 

Akár FOR XML-lel, akár XML nézettel is generálunk XML adato- 
kat, a könnyebb kezelhetőség illetve a belső részletek elfedése 
végett érdemes az adatforrásunkat XML sablon mögé rejteni. 
Az XML sablonok felépítése nagyon egyszerű. Lássunk is 
mindjárt egy vázat: 


c?xml version-z"1.0" encoding-"ISO8859-2"?5 
ccourses 
xmlns:sg1-"urn:schemas-microsoft-com:xml-sgli"5 
csgl:header5 
csal:param name-"CourseIDs"531905c/sal:param: 
£/sagl:header5 


£Zsal:guery2 
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exec webGetCourseXML ECourseIDs 
£/sagl:guery2 


£/coursesz 


A sablon nem más, mint egy jól formázott XML dokumentum, 
amelyben az SOL Server specifikus elemeket az 
urn:schemas-microsoft-com:xml-sgl. névtérből származtatjuk. A 
ccoursesz-c/coursesz a sablon gyökérelemét képező xml elem, ez 
lesz a sablon által generált xml dokumentum gyökéreleme is. 

A header részben adhatjuk meg a paraméterek listáját, 
amelyeket a sablonra hivatkozó URL-ekben adhatunk meg. 
Lehet alapértelmezett értéket is adni, így például a CourseIDs 
paraméter értéke 1905 lesz, ha a sablon hívásakor nem ír- 
juk ki a paramétert. 

A guery elemek közötti részben kell megadni a sablon tartalmát 
adó xml adatforrást. Ez lehet egy XML kimenetű SOL lekérdezés, 
ahogyan az a példában is látszik. Közvetlen SOL parancsot is 
megadhatunk, de tárolt eljárásokat is használhatunk, mint a 
webGetCourseXML. Emellett XML sablont is megadhatunk adat- 
forrásnak, és annak a kimenetét pedig a már látott módon 
XPath kifejezésekkel szűrhetjük meg. Például az előző fejezetben 
összerakott nézetünket csomagoljuk be egy sablonba: 


£courses xmlns:sgl-"urn:schemas-microsoft-com:xml- 
sgi"5 
cSsgl:header? 
£Zsgl:param name-"CourseID"51905c€/sgl:param2 
£/sgl:header2 
£sgl:xpath-guery mapping- 
schema-" /nasglxm1l/views/sgl8sampleschemaview.xml"5 
tanfolyamok/tanfolyam[€Kod - $CourseID] 
£/sagl:xpath-guery? 


£/coursesz 


Ebben az esetben az adatforrást nem a guery, hanem az 
xpath-guery elemben adjuk meg, az XML nézetre a map- 
ping-schema attribútumban hivatkozva. Az XPath szűrési 
feltételt az elem belsejébe kell írni. 


Zárszó 

Végignéztük a lefelé irányt, az adatok XML formátumban tör- 
ténő elérését. Egy későbbi alkalommal a visszafelé iránnyal is 
foglalkozunk, az updategram-ok kérdéskörével, amelyekkel 
közvetlenül XML adatokat juttathatunk el az SOL Serverre. 

Aki szeretné alkalmazni az itt tanult tudást, az kérem lapoz- 
zon át az XMLGessünk cikkünkre, amely megmutatja a gya- 
korlati felhasználását az itt felépített XML adatforrásoknak. 


Soczó Zsolt MCSE, MCSD, MCDBA 
Zsolt.Soczo (onetacademia.net 


[1]: XML Schema ajánlás http://www.w3.org/TR/xmlschema-O 

[21]: SOLXML2 Beta 1 http://msdn.microsoft.com 

3. /msdn-files/027/001/602/Search.asp 

[3]: Microsoft XML Parser 4.0 Technology Preview 
http://msdn.microsoft.com/xml/general/newinaprilre.asp 

[4]: http://technet.netacademia.net/download/sgl 
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XMLgessünk 
(IV. rész) 


Bevezetés 

Igazi csemegét van szerencsém bejelenteni. A kiszolgálóoldali 
HTML tartalomgenerálásnak nézünk a körmére, XSLT és adat- 
bázis-alapokon. A cikk most párban jár az SOL sorozat cikké- 
vel, az egyik kiegészíti a másikat. Érdemes az SOL-lel kezdeni, 
és azután belevágni az XML finomságokba, itt és most. 


A hagyományos ASP úton 

Hogyan működik a tartalom generálása , hagyományos" ASP 
eszközökkel készített, adatbázisalapú webalkalmazásokban? 
ADO kapcsolatot nyitunk az adatbázis-kiszolgálóra, például az 
SOL Serverre. A kapcsolaton keresztül végrehajtunk egy SOL 
parancsot, amelyek eredményhalmazát ADO Recordset objek- 
tumként kapjuk meg. Ez azonban nem más, mint egy (eléggé) 
intelligens tömb, amelyből még elő kell állítanunk valamilyen 
HTML tartalmat. Ehhez végig kell lépkednünk egy ciklusban a 
Recordseten, és az aktuális adatbázissor mezőit sztringművele- 
tekkel beleszerkesztjük a kimeneti adatfolyamba vagy sztring- 
be. Ez a gyalogosmódszer. Ezt csináljuk nap mint nap. 

Amíg csak egy egyszerű lekérdezés kimenetét, például egy 
tábla tartalmát kell HTML-é alakítani, addig a ,sztringhe- 
gesztős" megoldás elég átlátható tud maradni. Azonban a 
problémák akkor kezdődnek, amikor több táblából kell 
összeszedni a logikailag összetartozó információkat a meg- 
felelő tartalom megjelenítéséhez. Ilyenkor teljesítmény 
szempontjából az lenne az előnyös, ha az összes megjeleni- 
tendő információt sikerülne egy  eredményhalmazként 
visszakapnunk, egy hálózati körülfordulás alatt. Azonban ez 
általában nem szokott összejönni, vagy ha igen, akkor a ge- 
nerált eredményhalmaz olyan redundáns lesz, hogy a szük- 
ségesnél sokszor több információ fog utazni az adatbázis és 
a webalkalmazás között, mint amennyi kellene (lásd párhu- 
Zzamos SOL cikkünket). Ez akkor is nagy teljesítményveszte- 
séget fog okozni, ha a webkiszolgáló és az adatbáziskiszol- 
gáló egy és ugyanazon számítógépen vannak. 

Ezért kerülőmegoldásokat kellett kidolgoznunk. Például igen 
gyakori feladat, amikor valamilyen objektumokat (áruk, sze- 
mélyek, hírek, cikkek, ...) ki kellett listázni, és minden tétel- 
hez szükség volt további részletező adatokra is - más táb- 
lákból. Ekkor használtuk azt az eljárást, hogy lekérdeztük az 
alapadatokat, a kapott Recordsetből elkezdtük felépíteni a 
listát, és amikor az adott tétel részletes adataira volt szük- 
ség, akkor egy, a tétel azonosítójával paraméterezett lekér- 
dezéssel lehívtuk az adott elem további tulajdonságait. Ez 
azt jelentette, hogy ahány tétel volt a listában annyi plusz 
lekérdezést kellett végrehajtani minden egyes weboldal vég- 
rehajtásakor. Ennél jobban nehéz pazarolni az erőforrásokat 
(na jó, a memory leak azért durvább :). 

Milyen , szakos" megoldást kaptunk az ASP alapú rendszerek- 
ben erre rendkívül gyakori és triviális problémakörre? Semmi- 
lyet. Trükkös táblákat építhetünk JOIN és UNION operátorok 
segítségével, ám ezeknek nehéz kiolvasni, illetve megjelení- 
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teni a tartalmukat. Jött a szokásos kód - HTML elemek - kód 
- HTML elemek spagetti. Karbantarthatatlan, lassú, ronda. 
Amíg nincs ASP.NET-ünk, ami adatkötéssel bíró kiszolgálóolda- 
li vezérlőkkel (részben) megoldaná a problémáinkat, addig is 
érdemes fontolóra venni az XML-XSL-ben rejlő lehetőségeket. 
Ez nem azt jelenti, hogy a .NET után nem lesz létjogosultsága 
az XSL alapú megoldásoknak, csak azt, hogy abban már ka- 
punk nem XML alapon is olyan eszközöket, amelyek segítségé- 
vel viszonylag könnyen tudunk adatbázisalapú adatokat meg- 
jeleníteni. Legalább lesz alternatívánk. A kétféle megközelítés 
összehasonlításáról az [1] címen lehet bővebben olvasni. 
Maradjunk a végleges eszközöknél, és nézzük meg, hogy 
XSLT segítségével hogyan lehet az előbb vázolt listázási 
problémát megoldani. Az alapfelállás: van egy XML 
adatforrásunk, annak kimenetét szeretnénk XSLT-vel 
HTML-lé konvertálni. Adatforrásként ideális választás az 
SOL Server, erről bővebben ugyanezen szám SOL cikkében 
olvashat a Kedves Olvasó. 

A konverzió történhet ügyféloldalon (erről már részben ér- 
tekeztem a cikksorozat előző részében), illetve az XML-t 
közvetlenül nem kedvelő böngészők esetén kiszolgálóolda- 
lon. Most az utóbbival ismerkedünk meg. 


Belép az XML 

Nézzük először az adatforrás kérdését. Ami általában szóba 

jöhet: 

1. Közönséges XML állomány - ritkán van haszna, de például 
konstans táblázatok, legördülő listák forrásaként jó lehet 

2. Közvetlen SOL Server kapcsolat SELECT ... FOR XML... 
paranccsal, ADO eléréssel 

3. SOL Server XML sablon közvetlen XML DOM eléréssel 

4. SOL Server XML nézet XML DOM feldolgozással 

5. ..., például Exchange 2000, SharePoint Portal Server 

Jelen cikkünkben a második és a harmadik megoldást néz- 

zük meg részletesen, de minimális eltéréssel a negyedikre 

is érvényes lesz az ott leírt elmélet. 


Közvetlen adatbázislekérdezés 

A megoldás gondolatmenetét és a hozzá kapcsolódó 

JScript kódot láthatjuk a következő pontokban. 

1. ADO kapcsolatot nyitunk az SOL Serverre. A hibákat 
try-catch blokkban kezeljük le. 


try 
( 
var conNetAcademia -— 

Server.CreateObject ( "ADODB. Connection "ye 
conNetAcademia.CursorLocation - adUseClient; 
conNetAcademia . Open ( "ProvidersSOLOLEDB; " 

4 "Initial Catalog-Netacademia; " 
4 "Data Source-(local);" 
4 "Integrated Security-SSPI;"); 
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Létrehozunk egy ADO parancsobjektumot az SOL lekér- 
dezés végrehajtásához. 


var cmd -— 
Server .CreateObject ( " ADODB . Command" ) ; 
cmd.ActiveConnection - conNetAcademia; 


"emd.CommandText - strSOL; 
Létrehozunk és megnyitunk egy ADODB.Stream objektumot. 


var XMLStream - 
Server.CreateObject( "ADODB.Stream" ) ; 
XMLStream.Open( ) ; 


Végrehajtjuk az XML tartalmat generáló parancsunkat, 
az eredményt a Stream-be irányítjuk. 


cmd.Properties("Output Stream") - XMLStream; 


cmd.Execute(null, null, adExecuteStream); 


Lezárjuk az adatbáziskapcsolatot, a Stream tartalma 
attól még megmarad. 


conNetAcademia.Close( ) ; 


Létrehozunk egy DOMDocument objektumot. Ebbe kerül 
bele a lekérdezés által generált XML tartalom. 


var DomCourse — 
Server .CreateObject ( "MSXML2 . Dompocument " ) ; 


DomCourse.async -— false; 


A példában a lekérdezés eredményeként olyan XML do- 
kumentumtöredéket kapunk vissza, amelynek több 
mint egy gyökér eleme van. Ezért be kell illesszünk egy 
,Mesterséges" gyökeret, hogy jól formázott XML doku- 
mentumot kapjunk. 


var strXML - 

"c?xml versionsc"1.0" encoding-"ISO8859-2"?5" 
4 "ccoursesz! 

4 XMLStream.ReadText(adReadAll) 


4 "€/courses2"; 


Mehet a DOMDocument-be a Stream tartalma. Miután a 
loadXML metódus lefutott, a Stream tartalmára már 
nincs szükség, hisz a DOM-nak már van másolata az 
XML dokumentumból. Azaz lezárhatjuk a Stream-et. 


DomCourse . loadXML ( strXML) ; 


XMLStream.Close() ; 


Az első kódblokkunknak vége, a hibakezelő blokkunk is 
véget ér. Hiba esetén a ReportParseError és a 
GeneralErrorFormatter függvényekben reagáljuk le a hi- 
baeseményeket. Ezek forrása a [2] címen található. 


GeneralErrorFormatter (exception) ; 
if (DomCourse !- null) 


( 
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ReportParseError (DomCourse . parseError) ; 


, 


Response.End( ) ; 


10. Létrehozunk egy másik DOMDocument-et a stíluslap ré- 
szére, és betöltjük a stíluslapot. Mivel ő is egy szabá- 
lyos XML dokumentum, a DOMDocument szívesen ma- 
gába fogadja. 


try 
ú 
var DomXSL - 
Server .CreateObject ( "MSXML2 . DomDocument " ) ; 
DomXSL.async - false; 
DomXSL.load(strXSLPath) ; 
) 
catch(exception) 
1 
if (DomXSL !z null) 
( 
ReportParseError (DomCourse.parseError ) ; 
Response.End( ) ; 
, 
GeneralErrorFormatter (exception) ; 
Response.End( ) ; 
) 


11. A transzformáció előtt be kell állítani a kimenet karak- 
terkódolását (Central European), különben a böngésző nem 
fogja tudni milyen nyelvű a generált HTML dokumentum. 


Response.Charset - "ISO8859-2"; 


12. Végrehajtjuk a transzformációt, a kimenetet közvetlenül 
a Response objektumba irányítva (hatékonyság!). A 
transzformációt az XML forrást tartalmazó dokumentum- 
objektumon hajtjuk vége, paraméterként a stíluslap do- 
kumentumot és a kimeneti Stream-et, a Response-ot ad- 
juk meg. Kihasználjuk, hogy az ASP Response objektum 
implementálja az IStream COM interfészt, így a DOM tud- 
ja, hogyan kell vele kommunikálni. A Response-ba nyu- 
godtan írhatunk egyéb tartalmat a transzformáció előtt 
és után is. Azok összefűződnek az itt beírt tartalommal. 


DomCourse.transformNodeToObject (DomXSL, 


Response) 


13. Lezárjuk a hibakezelő kódot. 


, 
catch(exception) 
€ 
GeneralErrorFormatter(exception) ; 
p 


A teljes kód gazdagon kommentezve a [2] címen érhető 
el, ahol ki is lehet próbálni élő adatokkal. 
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Adatelérés XML sablonon keresztül 
Az előbbi példa talán legbonyolultabb része az adatbázist le- 
kérdező kód volt. Mivel az SOL Server XML formátumú kimene- 
tét minden további nélkül elérhetjük közvetlenül HTTP proto- 
kollon keresztül is, valamint kihasználva, hogy a DOMDocu- 
ment load metódusa URL-t is elfogad forrásként, jelentősen 
leegyszerűsíthető a forrásadatok megszerzésének folyamata. 
Az SOL Server XML sablonok illetve XML nézetek segítsé- 
gével képes XML tartalmat HTTP-n keresztül szolgáltatni. 
Az XML sablon mögött vagy egy FOR XML... végű SELECT 
SOL lekérdezés áll, vagy egy XML nézet. Az XML nézet köz- 
vetlenül is megcímezhető XPath kifejezés segítségével. 
Részletek az SOL cikkünkben. 
Az adatbázisháttér részletei jelen pillanatban nem fonto- 
sak, a lényeg, hogy van egy olyan URL-ünk, amiről XML for- 
mátumú adatok érkeznek. Erről az URL-ről az XML DOM köz- 
vetlenül le tudja tölteni az XML forrásdokumentumot, így 
elfelejthetjük az ADO objektumokat. Ennek megfelelően 
nézzük meg, hogyan változik a programunk első része. 
1. Definiáljuk a forrásainkat. Az első változóba töltött URL 
egy (az online verzióban paraméterezhető) XML sab- 
lonra mutat. 


var strXMLPath - "http://" 

4 Reguest.ServerVariables ("SERVER NAME") 
4 "/nasglxml/template/course.xml" ; 

var strXSLPath — 


Server.MapPath( "course.xsl"); 


2. Létrehozunk egy XML DOMDocument objektumot. Nagyon 
fontos látnunk, hogy most speciális helyzetben fogjuk 
használni a DOM-ot: webalkalmazásban futtatva egy 
webkiszolgálón (akár önmagán) található HTTP erőfor- 
rást fogunk elérni. Erre fel kell készíteni a dokumentum- 
objektumunkat, mivel ez speciális igénybevételt jelent 
neki. Ehhez a ServerHTTPReguest tulajdonságát kell 
beállítani true-ra, így a háttérben nem az XMLHTTP, ha- 
nem a ServerXMLHTTP objektum tölti le az URL-ről az 
XML adatokat. Csak ez működik kiszolgálóoldalon! 


var DomCourse - 

Server.CreateObject ( "MSXML2 . DomDpocument " ) ; 

DomCourse.async - false; 

77111 

DomCourse.setProperty( " ServerHTTPReguest" , 
true); 

DomCourse.load(strXMLPath) ; 


Ettől a ponttól kezdve minden ugyanaz, mint az előző 
példában, azaz XSL betöltés majd transzformáció követke- 
zik. 4 sorral megúsztuk az XML adatok betöltését! 
Gondolhatnánk, hogy a járulékos réteg, a webkiszolgáló 
megjelenése az adatfolyamban jelentősen lassítja a lap 
generálását. A méréseim alapján azonban gyakorlatilag 
nem volt különbség a két módszer között. Ez különösen 
akkor igaz, ha az SOL Server plusz a HTTP eléréshez szük- 
séges IIS és a valódi webkiszolgáló külön gépen vannak. 
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DEVELOPER XMLGESSÜNK (IV.RÉSZ) 
XSLT Cache alkalmazása 

Az előbbi két példában volt egy közös pont, ami jelentős 
teljesítményveszteséget okoz egy nagyterheltségű webalkal- 
mazásban. Ez pedig az XSL dokumentum betöltése és lefor- 
dítása. A legtöbb esetben a stíluslapok eléggé állandóak, 
ritkán módosítják őket. Ennek ellenére mi minden egyes lap 
legenerálásakor betöltjük és lefordíttatjuk az XSL dokumen- 
tumot. Nem lehetne valahogyan globálisan, minden lap szá- 
mára látható módon előkészíteni egy XSL-t tartalmazó ob- 
jektumot, és azt minden lapban felhasználni? A Microsoft 
XML DOM implementációja ehhez hathatós segítséget nyújt. 
Milyen központi helyünk van a közös objektumok tárolásá- 
ra? Természetesen a global.asa. Ott az Application OnStart 
eseményben létrehozhatunk olyan alkalmazásszintű objek- 
tumokat, amelyek minden lap számára láthatóak lesznek. 
Az alkalmazásszinten létrehozott objektumokkal szemben 
igen erős követelmények vannak, mert egyszerre sok lap, sok 
thread használhatja őket. Az eddig használt DOMDocument 
objektumunk nem állná ezt a rohamot (mint ahogy az összes 
VB6-ban írt objektumunk sem!) , helyette a FreeThreadedDOM- 
Document komponensből kell egy példányt létrehoznunk. Ő 
free-threaded (Multi Threaded Apartment) modellű objektum, 
amely fel van készítve a párhuzamos felhasználásra. 

Mivel a legtöbb időt nem is az XSL fizikai betöltése, hanem 
a lefordítása jelenti, ezért a Microsoft XML DOM-ban létre- 
hoztak egy XSLTemplate nevű egyedet, aki lefordított XSL 
stíluslapot képes tárolni. A többszálú felhasználás miatt 
nem is tárol szálhoz kapcsolódó adatokat. Azonban a konk- 
rét transzformációk végrehajtása során kellene állapotinfor- 
mációkat is tárolni, például a későbbiekben részletezett pa- 
ramétereket. Mivel párhuzamosan több transzformáció is 
működhet a webkiszolgálón (ne felejtsük, az IIS többszálú) , 
így vagy az XSLTemplate-nek kellene megjegyezni, hogy 
melyik hívó szál transzformációja hányadán áll, vagy létre- 
hozunk egy másik objektumot immár nem alkalmazás, ha- 
nem lapszinten, így abban már tárolhatunk lap (szál) függő 
információkat. Az első megoldás kevesebb memóriafelhasz- 
nálással jár, de sok szál esetén lassúvá válna a szálak kö- 
zötti szinkronizáció miatt. A második megoldás több me- 
móriát igényel, hisz annyi másolatobjektumot kell létrehoz- 
ni, ahány lap fut egyszerre. A Microsoft - mint a legtöbb 
esetben - nagyon helyesen a sebesség mellett döntött. 

Az XSLTemplate-nek van egy testvére, az XSLProcessor. Ami- 
kor konkrétan transzformálni szeretnénk egy weblapban, ak- 
kor a globálisan eltárolt XSLTemplate createProcessor metó- 
dusának meghívásával kapunk egy XSLProcessor objektumot. 
Ez már könnyedén áttranszformálja a korábban látott mód- 
szerek valamelyikével felépített forrás DOMDocument objek- 
tumunkat a transform metódus hívásával. 

Ültessük át a gyakorlatba az eddigi monoton elméletet! 
Nézzük át lépésenként, mi a teendőnk a global.asa-ban. 


1. A webalkalmazás elindulásakor létrehozunk egy 
XSLTemplate objektumpéldányt. 


XSCRIPT LANGUAGE-JScript RUNAT-Server5 
function Application OnStart() 
ű 


var XSLTemplate - 
new ActiveXObject ( "MSXML2.XSLTemplate" ) ; 
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DEVELOPER XMLGESSÜNK (IV.RÉSZ) 

2. Létrehozunk egy FreeThreadedDOMDocument objektu- 
mot az XSL stíluslap betöltéséhez, és betöltjük az XSL-t 
tartalmazó állományt. 


var xslDoc - 
new ActivexXObject( 

"MSXML2 .FreeThreadedDOMDOcument " ) ; 
xslDoc.async - false; 


xs1lDoc.load(Server.MapPath( "course.xsl")); 


3. Elkészítjük az XSLTemplate-et. A forrása természetesen 
a már betöltött stíluslapunk lesz. 


xSLTemplate.stylesheet - xslDoc; 


4. Az DOMDocument elvégezte a dolgát, mehet. A sablon- 
nak már megvan a lefordított XSL, nincs szükség többé 
a forrásra. 


xslDoc - null; 


5. Tároljuk el a sablont egy alkalmazásszintű változóba, hogy 
a lapok felhasználhassák. Ezzel vége is az eseménykeze- 
lőnek, zárjuk le a függvényt és a scriptblokkot is. 


Application("XSLTemplate") - XSLTemplate; 


§ 
€/SCRIPT2 


Ennyi a global.asa története. Most lássuk, mit kell tennünk 
a weboldalakban a sablon használatához. 

Az első példánk 11. lépéséig, azaz a karakterkészlet beállí- 
tásáig minden ugyanaz, azaz megszerezzük a forrás XML 
adatokat egy DOMDocument objektumba. Ezután fog kü- 
lönbözni a feldolgozás. 


1. Létrehozunk saját XSLProcessor példányt a globálisan 
előállított sablon createProcessor metódusával. 


xslProc -— 


Application("XSLTemplate" ) .createProcessor( ) ; 


2. A processzor input paraméterében átadjuk a transzfor- 
málandó forrásobjektumunkat. 


xslProc.input - DomCourse; 


3. Végrehatjuk a transzformációt. A végeredményt nem 
kapjuk meg visszatérési értékként, hanem az output 
tulajdonságon keresztül férhetünk hozzá. 


xslProc.transform( ) ; 


Response.Write(xslProc.output) ; 


A szenzációs az ebben a sablonobjektumot alkalmazó mód- 
szerben, hogy ez a legegyszerűbb és a leggyorsabb az ed- 
digi példáim közül. Egy felhasználó esetén persze nem so- 
kat nyerünk, de egy normális webalkalmazást általában 
nem egy ember használ (ha igen, akkor úgyis bezár :)) 
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Paraméterek átadása az XSLT-nek 

Sokszor feladat az (lásd a cikksorozatunk előző része), hogy 
egy adott XSLT transzformációba egy-két változót kellene 
becsempészni, amit a konkrét meghíváskor állítunk be. 
Semmi probléma. Nem véletlenül fejtegettem a threading 
modelleket az XSLTemplate és a XSLProcessornál. Az 
XSLProcessor rental-threaded, így neki lehetnek szálhoz 
kötött adatait, nem véletlen, hogy minden lap külön pél- 
dányt hoz létre belőle. S ha már laponként egyedi a pro- 
cesszor, miért ne lehetne neki paramétereket átadni, ame- 
lyek megjelennének a transzformációnkban? 

Az XSLT nyelvtana megengedi paraméterek definiálását, ame- 
lyeket az XSLT processzornak futásidőben adunk át. A paramé- 
tereket a XSLT-ben az cxsl:paramz elemmel lehet létrehozni: 


€xsl:param name-"sorrend" /5 


Értéket az XSLT-ben nem adunk neki, majd az XSLT pro- 
cesszoron keresztül tesszük ezt. Hogyan hivatkozhatunk az 
XSLT-ben a paraméterre? A nevével, egy $ jelet írva eléje. 
Például, ha egy XSLT-vel történő sorbarendezésnél a sorba- 
rendezés irányát szeretnénk paraméterrel megadni, akkor 
azt a következőképpen fejezzük ki: 


xsl:sort select-"" order-($sorrend) /5 


A paramétert ebben az esetben cxsl:stylesheet ...2-en be- 
lül hozzuk létre globálisan. 

Jöhet az XSLProcessor. Van neki egy addParameter metó- 
dusa, amelyben meg kell adni a behelyettesítendő paramé- 
ter nevét és értékét. Ezt behelyettesíti az XSLT-be, ami 
után végrehajthatjuk a transzformációt. 


xslProc. addParameter("sorrend", "descending"); 


Nyilván amennyi paraméterünk van, annyiszor kell alkal- 
maznunk a metódust. 


Zárszó 

Az XML technológiák ismertetése nagyon papírigényes, ezért 
a működő példáknak csak a tizede látható az újságban, pa- 
píralapon. A virtuális esőerdőt azonban nem kíméltem, így 
aki közelebbről is szeretné megnézni működés közben, teljes 
szépségében a példákat, kérem látogasson el a [2]-es címre. 
Nyáron az XMLGessünk is elmegy hűvösebbre, de ez nem 
jelenti azt, hogy hűvösre tettük a témát, csak azt, hogy 
pihen egy kicsit. De ősszel újult erővel, akkor már (mi 
más, ha nem) .NET alapokon fogunk XMLGetni. 


Soczó Zsolt MCSE, MCSD, MCDBA 
Zsolt.Soczo(onetacademia. NET 


A cikkben szereplő URL-ek: 


[1]: A Practical Comparison of XSLT and ASP.NET 
http://msdn.microsoft.com/library/Welcome/ 

6. dsmsdn/xml02192001.htm 

[2]: http://technet.netacademia.net/feladatok/xml 
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Aktív 


és passzív FIP 


Gyakran (főleg tűzfalak konfigurálása során) felmerül az a 
kérdés, hogy mi a különbség az aktív és a passzív FTP kom- 
munikáció között? 


Párosan szép az élet... 

Az FTP érdekes állat: amellett, hogy tisztán TCP alapon műkö- 
dik, azok közé a protokollok közé tartozik, amelyek egy-egy 
kommunikáció során nem egy, hanem két csatornát tartanak 
nyitva. Ez a két csatorna a parancs (command vagy control) és 
az adat (data) csatorna. A paranccsatorna a kliens dinamikus 
portjáról a kiszolgáló 21-es (FTP) portjára nyílik, míg az adat- 
csatorna a ügyfélgép egy másik (de továbbra is az ftp kliens- 
program által kézbentartott) portja és a kiszolgáló 20-as (FTP- 
"DATA) portja között épül fel - legalábbis az esetek egyik ré- 
szében. Az aktív és passzív FTP közötti különbség pontosan az 
adatcsatorna hollétében van. 


Aktív FTP 

Aktív FTP esetén az ügyfélalkalmazás egy dinamikus portról 
(pl. 4365) a kiszolgáló 21-es portjára csatlakozva felépíti a 
parancscsatornát. Az adatcsatorna felépítését a kiszolgáló 
kezdeményezi, mégpedig a (kiszolgáló) 20-as portjáról a 
kliensalkalmazás által kézben tartott következő szabad di- 
namikus portra (pl. a 4366-ra). Ez utóbbi portcím a továb- 
bi kommunikáció során mindig változik, azaz az egyes adat- 
csatornák mindig más dinamikus portra érkeznek (de min- 
dig a kiszolgáló 20-as portjáról indulnak) , valahogy így: 














Kiszolgáló Ügyfél 

















oD Aktív FTP 


A bejelentkezéskor csupán a 21-es portra csatlakozunk, míg 
a dir parancs kiadásakor új csatorna jön létre, a kiszolgáló 
20-as és a kliens 4366-os portja között. 

Az aktív FTP-ben az adatcsatornát nem a kliens építi fel: ő 
csak ,kinyitja" a következő portot, annak címét elküldi a ki- 
szolgálónak (PORT parancs a paranccsatornán), és várja a 
csatlakozást. Pontosan ez a probléma: az adatcsatorna fel- 
építését a kiszolgáló kezdeményezi, ezt pedig a tűzfalak 
többsége érthető biztonsági okokból nem engedi. 
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DUPLA 


Egy megoldás van azért: ha a tűzfal , okos", és figyeli az FTP 
kommunikáció tartalmát, kiolvashatja a kiszolgáló részére 
elküldött portcímet, és ebben az egyetlen esetben engedé- 
lyezheti a kapcsolatfelvételt. 


Passzív FTP 

A kiszolgálóoldali kapcsolatfelvétel elkerülése érdekében ta- 
lálták ki a passzív FTP-t. Ebben az esetben, miután a kliens 
felépítette a paranccsatornát (a 21-es portra), PORT parancs 
helyett PASV parancsot küld át rajta, a kiszolgálót ezzel át- 
kapcsolva passzív üzemmódba. A kiszolgáló erre megnyit egy 
portot (példánkban a 2277-est) a leendő adatcsatorna részé- 
re, és most ő küldi vissza az újonnan nyitott port címét (a 
PORT paranccsal) az ügyfélnek, aki ezután felépíti a második 
kapcsolatot, immár a két dinamikus port között. A dinamikus 
portcímek persze változhatnak, és az egyes adatcsatornák 
most is mindig új portcímre épülnek ki. 


Kiszolgáló 


20 21 
Data Cmd 


UTAT 
4397 4398 
Cmd Data 


2277 


o Passzív FTP 


Az ügyfélprogramok többsége csak a passzív FTP-t támogat- 
ja, bár az Internet Explorer-nél külön be kell kapcsolni, ha 
használni szeretnénk. A Tools / Internet Options párbeszéd- 
ablak Advanced oldalán jelöljük be az , Use Passive FTP for 
compatibility with some firewalls and DSL modems" sort. 
Míg a passzív FTP a kliensoldali problémákat megoldja, a ki- 
szolgálóoldalon újabbakat okozhat: hiszen ilyenkor a kiszol- 
gálónak kell minden egyes látogató részére adatcsatorna- 
portokat nyitogatnia, és a portok bizony egy idő után el- 
fogyhatnak. A megoldás az intelligens tűzfalak és az aktív 
FTP használata lehet. 


Fülöp Miklós 
mick Onetacademia.net 
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BILL GATES MONDJA 


Középiskolás voltam, amikor először olvastam egy cikkben 
- amit barátom, Paul Allen talált az Electronics magazin- 
ban - a mikroprocesszorról. Paul és én ekkor már írtunk 
szoftvereket, de ez a cikk ráébresztett arra, hogy pénzt is 
kereshetnénk ezzel. Akkor még nem voltak olyan cégek, 
amelyek kizárólag szoftverfejlesztéssel foglalkoztak, a szá- 
mítógépgyártók (például IBM és Digital) saját egyedi szoft- 
vereket készítettek gépeikhez. Természetesen nem akarták, 
hogy Paul vagy én készítsük el ezeket. 

Az Intel mikroprocesszorai ezt a helyzetet egy csapásra 
megváltoztatták. Először is, az Intel nem gyártott számító- 
gépet vagy szoftvert, bár ahhoz, hogy bármit kezdeni lehes- 
sen vele, új chip-jükhöz szoftverre volt szükség, így Paul és 
én lehetségesnek láttuk egy szoftvercég beindítását. Másod- 
szor, világosan látszott, hogy a mikroprocesszor a gyártási 
költségek csökkentésével, és az új képességek megvalósítá- 
sával teljesen átformálja a számítógépipart. 

Az Intel új chip-jének hirdetése, az , Integrált elektronika új 
korszakának bemutatása" igen előremutatónak bizonyult. 
Amikor Ted Hoff (Federico Faggin-nal és Stan Mazor-ral közö- 
sen) az Intel-nél kifejlesztette a mikroprocesszort, nem gon- 
dolta, hogy megváltoztatja a világot. Amikor az Intel egyik 
vásárlója azt kérte, hogy számológépekhez készítsenek vagy 
egy tucat egyedi chip-et, Hoff úgy gondolta, hogy egyszerűbb 
egyetlen általános célú chip-et gyártani, amely majd a szoft- 
ver segítségével képes lesz ellátni a különböző feladatokat. 
Ennek eredménye lett az Intel 4004 mikroprocesszor, ami szi- 
líciumdarabkára épített 2300 apró tranzisztorból állt, és tulaj- 
donképpen egy számítógép volt, egyetlen chip-en. 1971-ben 
mutatták be, és egy egész iparágat alapoztak meg vele. 


Nem egészen PC 

A mikroprocesszor megváltoztatta az én életemet is, annak 
segítségével, ami a , Világ első miniszámítógép készlete" - a 
MITS Altair 8800 - lett. A Tiltott bolygó (Forbidden Planet) 
című film egyik világa alapján elnevezett, 1975-ben kiadott 
Altair egy Intel 8080-as mikroprocesszorra épült, és keve- 
sebb mint 400 dollárba került, de nem lehetett semmi hasz- 
nosat tenni vele. Nem volt billentyűzete, képernyője és nem 
volt szoftvere sem, ezért Paul és én létrehoztunk egy társu- 
lást, amit Micro-Soft-nak hívtunk, és írtunk néhány szoftvert, 
ami képessé tette az Altair-t néhány egyszerű feladat elvég- 
zésére. Hat évvel később, amikor az IBM kiadta az első mo- 
dern PC-t, mi készítettük hozzá az operációs rendszert. 

A mikroprocesszorra épülő PC-k megváltoztatták a világot. For- 
radalmasították információink összegyűjtését, tárolását és fel- 
használását, a kommunikációt, a munkát, a tanulást és a játé- 
kot. Húsz éve még senki nem használt számítógépet, csak ha 
ez volt a hobbija, vagy a munkája. A mai PC-k fejlett szoftverei 
és több mint 9 millió tranzisztort tartalmazó mikroprocesszorai 
segítségével még egy gyereknek is rendelkezésére állhat egy ré- 
gi mainframe gépénél nagyobb számítási teljesítmény. 
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A mikro- 


processzorok 


hatása 


Egy olcsó otthoni PC-vel vezethetjük a házi költségvetésün- 
ket, elkészíthetjük adóbevallásunkat, levelezhetünk a bará- 
tainkkal, CD-t és rádiót hallgathatunk, híreket olvashatunk, 
tanácsot kérhetünk orvosunktól, játszhatunk, elintézhetjük 
nyaralásunkat, megnézhetünk egy házat, vagy akár autót is 
vehetünk... a lista végtelen. 


A mindenütt megjelenő chip 

Manapság a mikroprocesszorok mindenütt jelen vannak: 
mobiltelefonokban, CD lejátszókban, autókban, de legna- 
gyobb hatása a PC-kben való alkalmazásuknak van. 

A PC és az Internet együttesének segítségével az informá- 
ciók és hírek gyorsabban és szabadabban jutnak el rendel- 
tetési helyükre, segítve ezzel a zárt gazdaságok megnyitá- 
sát, és az elnyomott nemzetek demokratizálódását, mert a 
kibertérben nem lehet határokat építeni (Dehogynem! :) - 
a ford.). A mikroprocesszorra épülő PC-k több szabadságot 
biztosítanak az embereknek, és lehetővé teszik, hogy kezd- 
jenek valamit a szabadságukkal. Nem meglepő, hogy az 
idén 30 milliárd mikroprocesszort adnak el, és jövőre már 
lehet, hogy több PC-t vesznek, mint TV-t. 


Tessék kapaszkodni! 

Még csak a digitális kor küszöbén járunk. Az elmúlt két év- 
tizedben a mikroprocesszorok teljesítménye több mint egy- 
milliószorosára nőtt, de lehet, hogy ez a következő húsz 
évben megismétlődik, és a processzorokban talán majd 
egymilliárd tranzisztor lesz. 

A következő években még biztos a PC lesz a fő számítástechni- 
kai eszköz, de hozzá lesznek kapcsolva olyan mikroprocesszor- 
ra épülő eszközök, melyek még egyszerűbbé teszik életünket, 
és tudni fogják, mikor milyen információra van szükségünk. 


Egy valóban intelligens ház 
Otthon majd a hangunkkal fogjuk irányítani a PC-nket, ami 
automatikusan mentést készít az információinkról, frissíti a 
szoftverét, és szinkronizálja magát a TV-vel, a mobiltelefon- 
nal, a kézi PC-vel és az otthoni hálózatunk összes eszközével. 
A hűtőgépünk tudni fogja, hogy mennyi étel van benne, és 
recepteket fog ajánlani. A TV-nk segítségével megrendelhet- 
jük majd a reklámban látott terméket, ha pedig éppen nem 
lesz kedvünk TV-t nézni, olvashatjuk elektronikus könyvünket, 
ami tudni fogja, hogy kik a kedvenc szerzőink, és automati- 
kusan letölti legújabb műveiket. Ha úgy döntünk, hogy ezek 
egyikét elolvassuk, az árával megterhelődik a bankszámlánk. 
Úgy hangzik, mint egy fantasztikus regény? Ez néhány éve 
még tényleg így lett volna, de a mikroprocesszornak, vala- 
mint a szoftverek, a hardverek, az Internet és a telekom- 
munikáció hihetetlen fejlődésének köszönhetően minden 
amit leírtam, megvalósítható. 

Bill Gates 


tech.net 


A ,tech.net magazin Brainstorm" a Dupla KV rovathoz 
hasonló, ám a személyes kérdésfelvetést és vitát is le- 
hetővé tevő rendezvény, melynek célja: 


e az elsőre talán ismeretlen technológiák 
élő bemutatása 

s a cikkekhez kapcsolódó kódok 
megírása/kipróbálása 

s a terjedelmi okokból kimaradt 
információk átadása 


E magazinnal együtt a rendezvényre érvényes belépő- 


jegyet minden előfizetőnkhöz eljuttattuk. 
További információk a belépőjegyen olvashatók. 


Várjuk Önöket a 
NetAcademia Mesterkurzusokon 
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(Bár belépőjegyet adtunk, ez a tény önmagában nem biztosítja helyét a rendezvényen, A jegy célja előfizetőink elsődlegességének biztosítása, de a korlátozott résztve- 
vői létszám (100 fő) miatt a regisztráció kötelező. Jelentkezzen, amíg nem késő!) 
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